概要
データベースのパスワードやAPIキーをコードやAMIに埋め込まない、というのはセキュリティの基本です。では、それらをどこに置くか。AWSにはAWS Secrets ManagerとAWS Systems Manager Parameter Storeという2つの選択肢があり、SCS試験ではこの2つの使い分けが繰り返し問われます。
判断を分けるのは主に「件数」と「ローテーションが要るか」です。数千台規模のサーバーがそれぞれ認証情報を持つような構成では、シークレット1件あたり月額課金のSecrets Managerは費用が跳ね上がります。一方でParameter Storeの標準パラメータは保存に追加料金がかからず、SecureString型を選べばKMSによる暗号化と、IAMによる階層単位のアクセス制御が使えます。
この記事では、2つのサービスの違いを費用・機能の両面から整理したうえで、KMSカスタマー管理キーで暗号化したSecureStringパラメータを実際に作成し、取得と監査の流れを確認します。
クラウドおさる認証情報の置き場所は Secrets Manager か Parameter Store か、分かれ目は件数とローテーションの要否でござる。この記事では、カスタマー管理キーで暗号化した SecureString を作って、取得と変更履歴まで弊猿と一緒に確かめるでござるな。
この記事のメリット
- Secrets ManagerとParameter Storeの違いを、費用・ローテーション・共有の観点で説明できるようになる
- 標準パラメータとアドバンスドパラメータの違いを把握し、どちらを選ぶか判断できるようになる
- SecureStringとKMSキーの関係、復号に必要な権限を理解できる
- パラメータの階層構造を使ったIAMアクセス制御を設計できるようになる
- SCS試験で「大規模な認証情報管理でコスト効率の良い選択肢はどれか」という設問に正確に答えられるようになる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
2つのサービスの位置づけ
どちらも「秘密の値を暗号化して保管し、権限を持つ人だけが取り出せる」サービスです。決定的に違うのは、Secrets Managerがローテーションを含めたシークレットのライフサイクル管理サービスであるのに対し、Parameter Storeが設定値の保管庫である点です。
| 観点 | Secrets Manager | Parameter Store（SecureString） |
|---|---|---|
| 主目的 | シークレットの保管とローテーション | 設定値・秘密情報の保管 |
| 自動ローテーション | 組み込み（RDS等はマネージドで対応） | 組み込みでは無い（自前の仕組みが必要） |
| 暗号化 | KMSで暗号化（必須） | SecureString型を選ぶとKMSで暗号化 |
| リソースベースのポリシー | あり（クロスアカウント共有が容易） | 無い（アドバンスドパラメータでアカウント間共有に対応） |
| 保管料金 | シークレット1件あたり 0.40 USD/月 | 標準は追加料金なし、アドバンスドは1件あたり 0.05 USD/月 |
| API料金 | 10,000コールあたり 0.05 USD | 10,000インタラクションあたり 0.05 USD |
件数が増えたときのコスト差
この差が効いてくるのが大規模構成です。2,000件の認証情報を保管する場合を比べます。
| 選択肢 | 保管料金（月額の目安） |
|---|---|
| Secrets Manager | 2,000 × 0.40 USD = 800 USD |
| Parameter Store（標準） | 追加料金なし（保存数の上限は10,000件） |
| Parameter Store（アドバンスド） | 2,000 × 0.05 USD = 100 USD |
「2,000台のサーバーがそれぞれ認証情報を参照する」といった設問でParameter Storeが正解になるのは、この費用差が理由です。逆に、数十件のデータベース認証情報を確実にローテーションしたい、という要件ならSecrets Managerが適します。ローテーションを自前で作る手間とリスクのほうが、月額数十ドルより大きいためです。
[!NOTE] S3にファイルとして置く選択肢は、暗号化もアクセス制御もできますが、パラメータ単位の細かな権限管理と変更履歴・監査の面で劣ります。Parameter Storeはパラメータごとのバージョン履歴を保持し、取得操作はCloudTrailに記録されます。
クラウドおさるSecrets Manager はシークレット 1 件ごとに月額がかかるので、件数が数千になると保管料金が膨らむのでござる。猿山でも、倉庫の棚 1 つごとに家賃を払う契約だと、棚を増やすたびにバナナが飛んでいくでござろう。逆に確実なローテーションが要るなら Secrets Manager、という切り分けでござる。
標準パラメータとアドバンスドパラメータ
Parameter Storeには2つの階層（ティア）があります。
| 項目 | 標準 | アドバンスド（コンソールの表記は「詳細」） |
|---|---|---|
| 保存できる数 | 10,000 | 100,000 |
| 値の最大サイズ | 4 KB | 8 KB |
| パラメータポリシー（有効期限・通知） | 使えない | 使える |
| AWSアカウント間の共有 | 対応しない | 対応する |
| 料金 | 追加料金なし | 1件あたり 0.05 USD/月 |
注意点として、標準からアドバンスドへのアップグレードはできますが、アドバンスドから標準へのダウングレードはできません。値のサイズやポリシーが失われる恐れがあるためです。まず標準で始め、8KBを超える値やパラメータポリシーが必要になった段階でアップグレードするのが安全です。
SecureStringとKMS
パラメータの型は3種類（String / StringList / SecureString）で、認証情報には SecureString を使います。SecureStringを選ぶと、値はKMSキーで暗号化されて保存されます。
使うKMSキーは2択です。
| キー | 特徴 |
|---|---|
AWS管理キー（alias/aws/ssm） | 指定しなければこれが使われる。キーポリシーを自分で編集できない |
| カスタマー管理キー | キーポリシーで「誰が復号できるか」を制御できる。ローテーションや削除も自分で管理する |
セキュリティ設計の観点ではカスタマー管理キーを選びます。IAMポリシーで ssm:GetParameter を許可しても、KMSキーポリシー側で kms:Decrypt が許可されていなければ値は取り出せません。つまり、IAMとKMSの二重の関門を作れます。逆に言うと、アプリケーションに権限を与えるときは両方が必要です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["ssm:GetParameter", "ssm:GetParameters", "ssm:GetParametersByPath"],
"Resource": "arn:aws:ssm:ap-northeast-1:111122223333:parameter/prod/db/*"
},
{
"Effect": "Allow",
"Action": "kms:Decrypt",
"Resource": "arn:aws:kms:ap-northeast-1:111122223333:key/<キーID>"
}
]
}
クラウドおさるIAM で ssm:GetParameter を許可しても、KMS キー側で kms:Decrypt が許可されていなければ値は取り出せぬのでござる。カスタマー管理キーなら二重の関門を作れる反面、アプリに権限を渡すときは両方を忘れずに付けるでござるぞ。
階層構造によるアクセス制御
Parameter Storeのパラメータ名はスラッシュで階層を表現できます。
/prod/db/password
/prod/db/username
/staging/db/passwordこの命名にしておくと、IAMポリシーのリソースをワイルドカードで区切るだけで、環境ごと・システムごとにアクセスを分離できます。上のポリシー例で parameter/prod/db/* と書いているのがそれです。GetParametersByPath を使えば、階層配下をまとめて取得することもできます。
大規模構成では、この「命名規則でアクセス境界を作る」設計が運用のしやすさを決めます。あとから階層を変えるとポリシーもアプリも直すことになるため、最初に決めておきます。
実践
KMSカスタマー管理キーを作成し、そのキーで暗号化されるSecureStringパラメータを階層構造で作成します。作成後、コンソールとCLIから値を取得し、変更履歴が残ることを確認します。
前提条件
- リージョン:
ap-northeast-1（東京） - KMS・Systems Managerの操作権限を持つIAMユーザーまたはロールでコンソールにログイン済みであること
- CLIでの確認手順を実施する場合は、同じ権限で
awsコマンドが実行できること
このハンズオンで作成するリソースは以下のとおりです。
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| KMSカスタマー管理キー | parameter-store-key | SecureStringパラメータの暗号化用 |
| SSMパラメータ | /lab/db/username（String） | 階層構造の確認用 |
| SSMパラメータ | /lab/db/password（SecureString） | KMS暗号化の確認用 |
[!NOTE] 作成するパラメータは標準パラメータ（追加料金なし）です。KMSカスタマー管理キーは1本あたり月 1 USD の課金対象で、日割りされます。
手順1: KMSカスタマー管理キーを作成する
AWSマネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。
上部の検索バーに KMS と入力し、表示された「Key Management Service」を選択します。
左側ナビゲーションの「カスタマー管理型のキー」を選択し、「キーの作成」をクリックします。
キーの作成は6ステップのウィザード（キーを設定 → ラベルを追加 → キー管理アクセス許可 → キー使用法アクセス許可 → キーポリシーの編集 → 確認）です。以下を設定して進めます。
- キーを設定 ─ キーのタイプ:
対称/ キーの使用法:暗号化および復号化 - ラベルを追加 ─ エイリアス:
parameter-store-key - キー管理アクセス許可・キー使用法アクセス許可: 自分のIAMユーザー（またはロール）を選択
最後の確認画面で「完了」をクリックし、キーが作成されたことを確認します。
手順2: 通常の文字列パラメータを作成する
上部の検索バーに Systems Manager と入力し、表示された「Systems Manager」を選択します。
左側ナビゲーションの「アプリケーション管理」→「パラメータストア」を選択し、「パラメータの作成」をクリックします。
以下を設定します。
- 名前:
/lab/db/username - 利用枠:
標準（既定） - タイプ:
文字列 - データ型:
text - 値:
labuser
「パラメータを作成」をクリックします。
手順3: SecureStringパラメータをカスタマー管理キーで作成する
再度「パラメータの作成」をクリックし、以下を設定します。
- 名前:
/lab/db/password - 利用枠:
標準 - タイプ:
安全な文字列 - KMS キーソース:
現在のアカウント - KMS キー ID: 手順1で作成した
alias/parameter-store-key - 値: 任意のダミーパスワード（例:
LabPassw0rd!）
「安全な文字列」を選ぶと、画面に「データベースの認証情報やAPIキーのようなシークレットには、自動ローテーションを備えたAWS Secrets Managerを推奨する」という案内が表示されます。技術解説で整理した使い分けが、コンソール上でも案内されています。
「パラメータを作成」をクリックします。
パラメータ一覧で /lab/db/ 配下に2つのパラメータが並び、タイプが String と SecureString になっていることを確認します。
手順4: 値の取得を確認する
/lab/db/password を開きます。「値」欄が暗号化された状態で表示されていることを確認し、「復号化された値を表示」のチェックボックスをオンにすると平文が表示されることを確認します。
CLIから取得する場合は、--with-decryption を付けないと暗号文のまま返ります。両方を実行して違いを確認します。
# 暗号文のまま返る
aws ssm get-parameter --name /lab/db/password
# 復号された値が返る（kms:Decrypt の権限が必要）
aws ssm get-parameter --name /lab/db/password --with-decryption階層配下をまとめて取得することもできます。
aws ssm get-parameters-by-path --path /lab/db --recursive --with-decryptionCLI では --with-decryption を付けないと暗号文のまま返ってきたでござるな。復号して取り出すには kms:Decrypt の権限が要る、という技術解説の話がここでも確かめられたのでござる。
手順5: 変更履歴を確認する
/lab/db/password の詳細画面で「編集」をクリックし、値を別の文字列に変更して保存します。
「履歴」タブを開き、バージョン1と2が記録されていることを確認します。誰がいつ変更したかはCloudTrailに記録され、パラメータ自体は各バージョンの値を保持します。
手順6: アドバンスドパラメータとの違いを確認する
「編集」画面を開き、「利用枠」の選択肢を確認します。コンソールの表記は 標準 と 詳細（Premium）で、ドキュメントでいう標準パラメータとアドバンスドパラメータにあたります。それぞれのタイルに保存できる数・値のサイズ・料金が並んでいます。
詳細 を選ぶと、画面の下に「パラメータポリシー」のセクションが現れ、パラメータの有効期限（絶対時間・相対時間）と通知ポリシーが設定できるようになります。
[!NOTE]
詳細に変更すると1件あたり月 0.05 USD の課金対象になり、標準には戻せません。確認だけなら「変更を保存」を押さず、「キャンセル」で画面を閉じます。
クラウドおさる大量の認証情報をコスト効率よく管理したいのか、自動ローテーションが要るのか、という要件の読み分けが問われる観点でござる。SecureString の復号に IAM と KMS キーポリシーの両方が絡むことも、あわせて押さえておきたいところでござるな。
まとめ
| 判断軸 | Secrets Manager | Parameter Store |
|---|---|---|
| 件数が多い（数百〜数千） | 1件0.40 USD/月で費用が膨らむ | 標準なら追加料金なし。アドバンスドでも1件0.05 USD/月 |
| 自動ローテーションが要る | 組み込みで対応 | 自前で作る必要がある |
| クロスアカウント共有 | リソースポリシーで容易 | アドバンスドパラメータで対応 |
| 値のサイズが大きい | 最大64 KB | 標準4 KB / アドバンスド8 KB |
- 大規模な認証情報管理では、Parameter StoreのSecureStringがコスト効率で有利になる
- SecureStringはKMSで暗号化され、カスタマー管理キーを使えばIAMとKMSキーポリシーの二重で復号を制御できる
- 標準からアドバンスドへの変更は一方向で、元に戻せない
- パラメータ名の階層構造がそのままIAMのアクセス境界になるため、命名規則は最初に決める
- ローテーション要件があるならSecrets Manager、無いならParameter Store、という切り分けが試験での判断基準になる
参照先
- AWS Systems Manager Parameter Store – AWS Systems Manager
- パラメータ階層を管理する – AWS Systems Manager
- Parameter Store パラメータを作成する – AWS Systems Manager
- AWS Systems Manager の料金
- AWS Secrets Manager の料金
- AWS Secrets Manager とは – AWS Secrets Manager
