サイトアイコン IT & ライフハックブログ｜学びと実践のためのアイデア集

AWS Secrets Manager完全ガイド：パスワード・APIキー管理を「ローテーション」と「監査」で仕組み化する（GCP Secret Manager / Azure Key Vault比較）

greeden
AWS Secrets Manager

AWS Secrets Manager

AWS Secrets Manager完全ガイド：パスワード・APIキー管理を「ローテーション」と「監査」で仕組み化する（GCP Secret Manager / Azure Key Vault比較）

先に要点（忙しい方向け）

  • AWS Secrets Managerは、パスワードやAPIキーなどの“シークレット”を安全に保管し、取得し、そして（重要なら）定期ローテーションまで含めて運用できるマネージドサービスです。:contentReference[oaicite:0]{index=0}
  • ローテーションは「Secrets Managerが管理するローテーション（Managed rotation）」と「Lambda関数で回すローテーション」の2系統があり、対象や要件で選べます。:contentReference[oaicite:1]{index=1}
  • バージョン管理は“ステージングラベル”で運用します。既定で AWSCURRENT があり、ローテーションでは AWSPENDING などのラベルを使って安全に切り替えます。:contentReference[oaicite:2]{index=2}
  • 料金は「保管するシークレット数」と「API呼び出し回数」が中心で、削除待ち（deletion）状態のシークレットは課金されない、という整理です。:contentReference[oaicite:3]{index=3}
  • GCPはSecret Managerで自動ローテーション“通知”をPub/Subに出し、実際の更新はワークフロー（Cloud Functions/Cloud Run等）で行う形が基本です。:contentReference[oaicite:4]{index=4}
  • AzureはKey Vaultがシークレットを暗号化して保存し、同名で更新すると新しいバージョンが作られます。削除の安全網としてsoft-deleteと復旧機能が明確に整理されています。:contentReference[oaicite:5]{index=5}

この記事が役に立つ方（具体的に）

まず、プロダクト開発チームの方です。環境変数にAPIキーを埋めてしまったり、設定ファイルにDBパスワードを置きっぱなしにしたりすると、漏えいだけでなく「誰がいつ変えたのか分からない」「ローテーションが怖くて先延ばし」という運用負債が積み上がりがちです。Secrets Managerは、取得と権限制御、そしてローテーションの“手順”を仕組みに寄せることで、チームの不安を減らします。:contentReference[oaicite:6]{index=6}

次に、SRE/運用担当の方です。障害対応で最も困るのは「秘密情報が絡む復旧」で、誰もが慎重になりすぎて遅れがちです。Secrets Managerはバージョンとステージングラベルで切り替えの作法があるため、作業を手順化しやすく、監査の説明もしやすくなります。:contentReference[oaicite:7]{index=7}

さらに、マルチクラウドや将来移行を見据えるアーキテクトの方にも向いています。GCP Secret ManagerとAzure Key Vaultは考え方が近い一方で、ローテーションの“標準形”（AWSはマネージド/テンプレ、GCPは通知起点、Azureはイベント起点で組むことが多い）が少し違います。その差を理解しておくと、設計がぶれにくいです。:contentReference[oaicite:8]{index=8}

1. AWS Secrets Managerとは：秘密情報を「保管」だけで終わらせないサービス

AWS Secrets Managerは、シークレットをライフサイクル全体で扱うことを目的にしています。単に暗号化して保存するだけでなく、必要なら自動ローテーションスケジュールを組める、と公式に説明されています。:contentReference[oaicite:9]{index=9}

ここで大切なのは、Secrets Managerの価値が「保存先」ではなく「運用の仕組み」だという点です。たとえば、ローテーションを人手でやると、(1)DB側のパスワード更新、(2)アプリ側の設定更新、(3)影響確認、(4)古い情報の破棄、(5)証跡、が分散して事故が起きやすくなります。Secrets Managerは、その分散を“ひとつの型”に寄せるための道具立て（バージョン、ラベル、スケジュール、ローテーション手順）を用意しています。:contentReference[oaicite:10]{index=10}

2. 仕組みの中心：バージョンとステージングラベル（AWSCURRENTを理解する）

Secrets Managerの運用は、バージョンと“ステージングラベル”で整理すると理解が早いです。シークレットは複数バージョンを持ち、既定で AWSCURRENT が付いたバージョンが「通常取得される版」になります。ドキュメントでは、Secrets Managerは既定で AWSCURRENT を返すこと、バージョンにラベルを付け替えられること、そして同じラベルは同時に2つのバージョンに付けられないことが説明されています。:contentReference[oaicite:11]{index=11}

ローテーション時によく出てくるのが AWSPENDING です。ローテーションの途中で新しい値を“保留版”として作り、検証できたら AWSCURRENT を新しい版へ移す、という切り替え作法を、ラベルで表現します。ラベルの付け替えAPIが「ローテーション中の版を追跡するために使われる」と明記されているため、ここを理解しておくと、ローテーション失敗時の原因切り分けが格段に楽になります。:contentReference[oaicite:12]{index=12}

サンプル（言葉でイメージするローテーション）

  • 現在のシークレット：Version A（AWSCURRENT）
  • 次の候補：Version B（AWSPENDING）を作る
  • DB側をVersion Bのパスワードに更新し、接続確認
  • 問題なければVersion Bに AWSCURRENT を移し、Version Aは“旧版”として残す（必要なら後で整理）

コードよりも先に、この“切り替えの物語”をチームで共有しておくと、緊急時でも判断が揃いやすいです。視覚的なコンソールに頼らず、ラベル名と状態で会話できるのも、アクセシブルな運用として利点があります。:contentReference[oaicite:13]{index=13}

3. ローテーションの2方式：Managed rotationとLambdaローテーション

Secrets Managerのローテーションは2つの形がある、と公式に説明されています。

3-1. Managed rotation：サービス側が回してくれるローテーション

「マネージドシークレット」の多くでは、Managed rotationとして、サービスがローテーションを構成・管理し、Lambda関数を使わない方式がある、と案内されています。:contentReference[oaicite:14]{index=14}
この方式は、運用負担が小さく、まず導入して回してみたい場合に向きます。

3-2. Lambdaローテーション：テンプレか自作で要件に合わせる

もう一つが「Lambda関数で回すローテーション」です。AWSはローテーション関数テンプレートを用意しており、ベストプラクティスを実装した“すぐ使える”関数として提供される、と公式に説明されています。:contentReference[oaicite:15]{index=15}
テンプレで足りない場合はカスタムローテーション関数を作る、というガイドも用意されています。:contentReference[oaicite:16]{index=16}

ここでの設計の勘どころは、「ローテーション対象が“どこにある資格情報か”」です。DB、外部SaaS、社内API、どれも“更新手順”が違います。テンプレが使える領域はテンプレに寄せ、例外だけカスタムにする、という方針にすると、保守が安定します。:contentReference[oaicite:17]{index=17}

4. 料金設計：シークレット数とAPIコール数で“増え方”が読める

Secrets Managerの料金は、基本的に「保管するシークレット数」と「API呼び出し回数」に基づく、と料金ページで説明されています。:contentReference[oaicite:18]{index=18}
さらに公式ドキュメントでは「削除対象としてマークされたシークレットは課金されない」旨が明記されています。:contentReference[oaicite:19]{index=19}

実務でのコツは、次の2点に集約できます。

  • シークレット分割の粒度：分けすぎると固定費が増えますが、まとめすぎると権限分離やローテーションの都合が悪くなります。
  • 取得頻度の設計：アプリが毎リクエストで取得しに行くのか、起動時に取得して一定時間キャッシュするのかでAPIコール数が変わります（要件と安全性のバランスで決めます）。

この“増え方”が読みやすいのは、セキュリティ施策をコストと一緒に説明したいチームにとって、大きな強みです。:contentReference[oaicite:20]{index=20}

5. よくある運用パターン：小さく始めて、でもルールは最初に決める

Secrets Manager導入で失敗しにくい進め方は、「最初から全部を移す」のではなく、事故リスクが高い順に“型”を作ることです。

パターンA：DB認証情報（まずはローテーションが効く領域）

  • 対象：アプリのDB接続ユーザー
  • 方針：ローテーションを定期化し、切替の手順をテンプレ化
  • 期待効果：退職者や外部委託の入れ替えがあっても、鍵の再配布で揉めにくい

ローテーションでは「シークレットとDB（またはサービス）の両方を更新する」と公式に説明されているため、DB側更新が必要な設計である点を最初に共有しておくのが大切です。:contentReference[oaicite:21]{index=21}

パターンB：外部APIキー（ローテーションは“通知＋手続き”に寄せる）

外部SaaSのAPIキーは、APIで自動更新できないこともあります。その場合は、Secrets Managerで更新バージョンを作り、切替タイミングと影響範囲（どのアプリが参照しているか）を明確にして、手続きとして回します。ラベルで切り替えられる構造は、こうした“半自動”の運用でも役立ちます。:contentReference[oaicite:22]{index=22}

パターンC：緊急対応（漏えい疑い時の即時切替）

漏えい疑いでは、速度と正確さが両立しにくいです。そこで、平時から「緊急時はこの順番でラベルを切り替える」「影響確認はこのチェックをする」を手順として整え、誰でも実行できる状態にしておきます。Secrets Managerの“ステージングラベルで版を追える”構造は、緊急手順の説明と相性がよいです。:contentReference[oaicite:23]{index=23}

6. GCP Secret Managerとの比較：ローテーションは“通知起点”が基本

GCP Secret Managerも、シークレットを安全に保管し、ローテーションを支える仕組みを持ちます。公式の概要では「自動でローテーションして要件に対応できる」と説明しつつ、ローテーションスケジュールのページでは、Secret Managerが指定した頻度・時刻に基づいてPub/Subトピックへ通知を送ることでローテーションを進める、と明確に書かれています。:contentReference[oaicite:24]{index=24}

つまりGCP側の標準形は、

  • Secret Managerが「回すタイミング」を通知し、:contentReference[oaicite:25]{index=25}
  • 受け取った側（Functions/Run/Workflow等）が「実際の更新」を行い、
  • 新しいバージョンを登録する、
    という構造になります。

料金も、運用の形に沿って「アクティブなシークレットバージョン」と「操作（アクセスリクエスト）」「ローテーション通知」に整理されており、見積りに落とし込みやすいです。:contentReference[oaicite:26]{index=26}

このため、GCPを主戦場にする場合は「通知を受けて回すワークフロー（Pub/Sub起点）をどこまで標準化するか」が、運用成熟度を左右します。

7. Azure Key Vaultとの比較：シークレットは“バージョニング＋保護（復旧）”が軸になりやすい

Azure Key Vaultは、トークン・パスワード・証明書・APIキーなどのシークレットを安全に保存し、厳密にアクセス制御できるサービスとして説明されています。:contentReference[oaicite:27]{index=27}
Key Vaultはシークレットに意味付けをせず、受け取ったデータを暗号化して保管し、識別子で取り出す、という性質も明記されています。:contentReference[oaicite:28]{index=28}

運用で押さえておきたいのは「同じ名前で更新すると新しいバージョンが作られる」点です。REST APIの説明でも、同名シークレットが存在する場合は新しいバージョンが作成される、と明記されています。:contentReference[oaicite:29]{index=29}
そして、削除事故への安全網としてsoft-deleteがあり、削除されたオブジェクト（キー/シークレット/証明書）は“削除済み状態”として保持され、復旧や完全削除ができる、と公式に整理されています。:contentReference[oaicite:30]{index=30}

一方で、シークレットの自動ローテーションについては、組織の要件に合わせてイベントや関数を組み合わせて自動化するアプローチが紹介されることが多いです（Key Vaultのイベントを起点にする案内など）。:contentReference[oaicite:31]{index=31}
このためAzureでは、「バージョニングと復旧を標準で押さえつつ、ローテーションは周辺サービスで手続き化する」という設計が現実的になりやすい印象です。

8. マルチクラウドでぶれない比較軸：秘密情報管理はこの7項目で決まります

Secrets Manager / GCP Secret Manager / Azure Key Vaultを横並びで選ぶとき、機能名の差よりも、次の7項目で整理すると判断が安定します。

  1. バージョニングの作法（AWSはステージングラベル、Azureは同名更新で新バージョン、など）:contentReference[oaicite:32]{index=32}
  2. ローテーションの標準形（AWSはManaged/Lambda、GCPは通知→実行、Azureはイベント起点で組むことが多い）:contentReference[oaicite:33]{index=33}
  3. 削除・復旧の安全網（Azureはsoft-delete/復旧が明確、など）:contentReference[oaicite:34]{index=34}
  4. 監査の取りやすさ（誰がいつ何を取得したかを追えるか）
  5. 料金の単位（AWSはシークレット数＋API、GCPはアクティブバージョン＋操作＋通知、Azureはトランザクション課金など）:contentReference[oaicite:35]{index=35}
  6. アプリ側の取り込み方（起動時取得、短期キャッシュ、更新通知への追従）
  7. 組織の運用文化（手順で回せるか、完全自動に寄せたいか、監査の粒度はどこまで必要か）

この7つが決まると、クラウドが違っても“設計の芯”が同じになり、運用の品質が上がります。

まとめ：Secrets Managerは「秘密情報を回せるチーム」を作るための基盤

AWS Secrets Managerは、シークレットを安全に管理し、必要なら自動ローテーションスケジュールまで含めて運用できるサービスです。ローテーションにはManaged rotationとLambdaローテーションがあり、テンプレやガイドで標準化しやすいのが強みです。:contentReference[oaicite:36]{index=36}
また、バージョンとステージングラベル（AWSCURRENT 等）で切替の作法が定義されているため、緊急時でも判断を揃えやすく、手順化が進みます。:contentReference[oaicite:37]{index=37}
料金もシークレット数とAPIコール数中心で、削除待ちのものは課金されないという整理があり、コスト説明がしやすいです。:contentReference[oaicite:38]{index=38}

GCPはローテーション通知をPub/Subへ送るモデルが明確で、ワークフロー設計が要になります。:contentReference[oaicite:39]{index=39}
AzureはKey Vaultのバージョニングとsoft-delete/復旧が強く、ローテーション自動化はイベント起点で組む設計が現実的になりやすいです。:contentReference[oaicite:40]{index=40}

最初の一歩としては、「本番DBの認証情報をSecrets Managerに移し、ローテーションの型（いつ・誰が・どう確認し・どう切り替えるか）を文章と設定で残す」だけでも十分に効果があります。小さく始めて、でも運用のルールは最初に丁寧に。そう進めると、秘密情報は“怖いもの”から“回せるもの”へ変わっていきます。

参考リンク（公式情報中心）

モバイルバージョンを終了