LASSIC Media らしくメディア
クラウドのシークレット管理(KMS)運用と外注の判断軸
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- ハードコードや平文管理による機密情報の漏洩リスクと、AWS Secrets Manager・KMSを使った保護された管理の仕組みを理解できます。
- ローテーション・最小権限・CloudTrail監査ログなど、実務で必要な運用設計の要点を把握できます。
- シークレット管理運用の料金体系とコスト最適化の考え方、専任が不在の場合の外注活用の進め方を学べます。
目次
クラウドのシークレット管理とは
クラウドのシークレット管理（Secrets Management）とは、クラウド上のシステムが動作するために必要な機密情報——APIキー・データベースパスワード・TLS証明書・OAuthトークンなど——を保護された状態で保管・配布・更新するための仕組みと運用プロセスを指します。AWS公式ドキュメント（2024年）では、「アプリケーションのソースコードに認証情報をハードコードすることなく、実行時にシークレットを動的に取得できる」ことがシークレットマネージャーの基本価値と定義されています*1。
シークレット管理が注目される背景には、クラウド環境の普及があります。オンプレミスのサーバー群とは異なり、クラウドではAPIを介したサービス間通信が増加し、管理すべき認証情報の種類と数が急増しています。データベース接続文字列・外部SaaSのAPIキー・コンテナ間通信のトークンなど、1システムだけで数十件にのぼるケースも珍しくありません。
こうした機密情報を適切に管理しなければ、コード漏洩・内部不正・設定ミスが直接的なデータ侵害につながります。シークレット管理の運用設計は、セキュリティ対策の中でもアプリケーション運用に直結する実務課題です。
ハードコード・平文管理の危険と典型事故
ハードコード（ソースコード内への直書き）と平文管理（設定ファイルへのベタ書き）は、シークレット漏洩の二大原因です。GitHubやGitLabに誤ってコードをパブリックリポジトリとして公開した瞬間、世界中に認証情報が露出します。
OWASP（Open Worldwide Application Security Project）の「Secrets Management Cheat Sheet」でも、ソースコードへの認証情報のハードコードや設定ファイルへの平文記載が漏洩リスクの典型として挙げられており、保管・払い出し・監査・ローテーションを一元管理する専用の仕組みを使うことが推奨されています*2。
典型的な事故パターンとして、以下の3つが挙げられます。
- 公開リポジトリへの誤プッシュ：開発者がローカルの`.env`ファイルをGitにコミットし、パブリックリポジトリへ誤ってプッシュ。不正アクセスに気付くまでにAWSリソースが無断利用される。
- 長期固定パスワードの使い回し：DBパスワードを年単位で変更しないまま運用。退職した元従業員が知るパスワードでアクセス可能な状態が続く。
- Dockerイメージへの混入：Dockerfileやビルドスクリプトに認証情報を埋め込んだまま、コンテナイメージをレジストリへ公開してしまう。
被害を受けた場合のコストは甚大です。IPA（情報処理推進機構）が2024年に公表した「情報セキュリティ10大脅威 2024」では、「内部不正・設定ミスによる情報漏洩」が組織向け脅威の上位に位置付けられており、クラウド設定ミスによる情報漏洩が継続的な課題であることが示されています*3。
内製でシークレット管理を行う場合、専任エンジニアには「セキュリティ設計・IAM権限設計・ローテーション自動化・監査ログ分析」の複数スキルが求められます。担当者が不在の状態で運用を継続すると、パスワード固定化・権限過剰付与・ログ無確認といった状態が蓄積されていきます。
AWS Secrets ManagerとKMSの役割分担
AWSのシークレット管理には主に2つのサービスが使われます。AWS Secrets Manager（シークレットの保管・配布・ローテーションを担うサービス）とAWS KMS（AWS Key Management Service、暗号化鍵そのものの生成・管理・保護を担うサービス）です。両者は異なるレイヤーを受け持ち、連携して使います。
AWS Secrets Manager：シークレットの一元保管と配布
AWS Secrets Managerは、データベース認証情報・APIキー・OAuthトークンなどをAPIを通じて保護された状態で保管・取得できるマネージドサービスです*1。アプリケーションはコード内に認証情報を持たず、実行時にSecrets Manager APIを呼び出してシークレットを取得します。
主な機能は以下のとおりです。
- バージョン管理：シークレットの変更履歴を保持し、必要に応じてロールバックが可能です。
- 自動ローテーション：マネージドローテーションまたはLambda関数を使い、スケジュールに従ってシークレットを自動更新できます。アプリケーション側の変更なしにローテーションを完了できるのが大きな特徴です*1。
- IAMポリシーによるアクセス制御：どのIAMロール・ユーザーがどのシークレットを取得できるかをポリシーで細かく制御できます。
- CloudTrail連携：シークレットへのすべてのAPIコールがAWS CloudTrailに記録されます。誰がいつ取得・変更したかを追跡できます*1。
AWS KMS：暗号化鍵の生成・管理・HSM保護
AWS KMS（AWS Key Management Service）は、暗号化に使う鍵（KMSキー）を生成・管理するサービスです。AWS KMSが保護するKMSキーは、FIPS 140-3 セキュリティレベル3検証済みのHSM（ハードウェアセキュリティモジュール）で保護されており、暗号化されていない状態でAWS KMSの外部に出ることはありません*4。
KMSとSecrets Managerの関係は「エンベロープ暗号化」という仕組みで理解できます。Secrets Managerはシークレットの値をデータキー（Data Key）で暗号化し、そのデータキー自体をKMSキーで暗号化します。KMSキーは直接データを暗号化せず、「データキーを暗号化する鍵」として機能します。
この分離により、シークレットの暗号化キーを定期的にローテーションしても、保存済みデータを再暗号化する必要がないという運用上の利点があります。
AWS Systems Manager Parameter Store との違い
AWSにはSecrets Managerと似たサービスとしてAWS Systems Manager Parameter Store（SSMパラメータストア）があります。両者の主な違いは以下のとおりです。
| 比較項目 | Secrets Manager | Parameter Store（Standard） |
|---|---|---|
| 主な用途 | DB認証情報・APIキー等の機密情報 | 設定値・環境変数・非機密パラメータ |
| 自動ローテーション | 対応（マネージドまたはLambda） | 非対応（手動のみ） |
| 料金 | $0.40/シークレット/月、APIコール$0.05/万件*5 | Standardパラメータは無料（Advancedは有料） |
| バージョン管理 | あり（100バージョンまで保持） | あり |
| KMS暗号化 | デフォルトで暗号化（aws/secretsmanagerキーは無料） | SecureString選択時のみKMS暗号化 |
ローテーションが必要なDB認証情報・外部APIキーにはSecrets Managerが適しています。アプリケーション設定値やフラグ管理にはParameter Storeのコストメリットが大きいです。用途に応じて使い分けることがコスト最適化の基本になります。
ローテーション・最小権限・監査ログの運用設計
シークレットを保護された状態で保管できる環境を整えた後は、継続的な運用設計が重要です。実務上の三本柱は「ローテーション（定期更新）」「最小権限（アクセス制御）」「監査ログ（証跡管理）」です。
ローテーション：短命化でリスクを下げる
シークレットを長期間固定すると、漏洩した場合の被害期間が長くなります。AWS Secrets Managerの自動ローテーションを使うと、スケジュール設定だけでDBパスワードやAPIキーを定期更新できます。AWS公式ドキュメントによれば、ローテーションには「マネージドローテーション（対象サービスがAWS側で処理）」と「Lambda関数によるローテーション（カスタムロジック）」の2形式があります*1。
マネージドローテーションはLambda関数の管理が不要で、Amazon RDS・Aurora・RedshiftなどのAWSサービスに対して設定できます。カスタムデータベースや外部SaaSのAPIキーにはLambda関数を使ったローテーションを実装します。
ローテーション実装時に注意すべき点は、「切り替え期間中の二重バージョン管理」です。古いバージョンのシークレットを参照しているアプリケーションが残存している場合、ローテーション後に認証エラーが発生します。事前に参照箇所を洗い出し、バージョン番号ではなく「AWSCURRENT」ラベルを使って取得する実装にしておくことが対策になります。
最小権限：IAMポリシーで取得範囲を絞る
IAM（AWS Identity and Access Management）のポリシーでは、「どのリソース（シークレットのARN）に対して」「どのアクション（GetSecretValue等）を」「どのプリンシパル（EC2インスタンスロール・Lambda実行ロール等）に」許可するかを細かく定義できます。
運用上のリスクは「過剰権限」です。全シークレットに対してAdmin相当の権限を付与したロールが存在すると、そのロールを乗っ取られた場合にすべての機密情報が露出します。アプリケーションごとに必要なシークレットのみを取得できる専用IAMロールを作成する設計が推奨されます。
監査ログ：CloudTrailで証跡を記録・保持
AWS CloudTrailを有効にすると、Secrets ManagerへのすべてのAPIコール（GetSecretValue・RotateSecret・DeleteSecret等）がログに記録されます。AWS公式情報によれば、CloudTrailは管理イベントの最初のコピーを無料で保存しますが、追加のトレイル設定やS3保存にはコストが発生します*1。
ログの保持期間は業種・規模によって異なりますが、PCI DSS（Payment Card Industry Data Security Standard、クレジットカード業界の国際的なセキュリティ基準）準拠が必要な場合は1年以上の保持が求められます。ログを保持するだけでなく、異常なアクセスパターン（深夜の大量取得・通常と異なるIPアドレスからのアクセス等）を検知する仕組みをAmazon CloudWatch AlarmやAWS Security Hubと組み合わせて構築することが実務上の次のステップです。
IaC/CIパイプラインとのリスクを抑えた連携
IaC（Infrastructure as Code、インフラをコードで定義・管理する手法）とCI/CDパイプラインにシークレット管理を組み込むことで、人手による認証情報の受け渡しを排除できます。
TerraformからのSecrets Manager参照
Terraform（HashiCorpが開発するオープンソースのIaCツール）では、`aws_secretsmanager_secret_version`データソースを使ってSecrets Managerからシークレットを読み込めます。Terraformのstateファイルにシークレットの値を保存しないよう、参照のみに留めることがポイントです。
ただし、Terraformの実行環境（CI/CDランナーなど）にも適切なIAMロールを付与し、シークレットを取得できるプリンシパルを限定する必要があります。
GitHub ActionsとSecrets Managerの連携
GitHub Actionsのワークフローからシークレットを取得する場合、OIDCを使うとAWSの一時的な認証情報を発行してSecrets Managerにアクセスできます。GitHubのシークレット機能（GitHub Secrets）もありますが、ローテーション自動化・監査ログ・アクセス制御の精度という観点では、Secrets Managerを正として一元管理し、CIからも参照する構成が運用上の管理工数を下げます。
コンテナ環境（ECS/EKS）での利用
Amazon ECS（Elastic Container Service）では、タスク定義にSecretsの参照を埋め込むことで、コンテナ起動時に自動的にシークレットを環境変数として注入できます。Amazon EKS（Elastic Kubernetes Service）では、Secrets Store CSI Driverを使ってPodにシークレットをマウントする方式が公式で推奨されています。
これらの仕組みを使うと、コンテナイメージやKubernetesのマニフェストファイルに認証情報を含めずに済みます。ただし設定ミスによりシークレットが環境変数から漏洩するリスクはゼロではないため、コンテナ間のネットワーク分離・実行権限の最小化とセットで設計する必要があります。
料金体系とコスト最適化の考え方
AWS Secrets ManagerとKMSを使う際のコストは、「保管するシークレット数」「APIコール数」「KMSキー数」の3軸で決まります。AWS公式の料金ページ（確認日：2026年6月）によれば、料金体系は以下のとおりです*5*6。
| サービス | 課金項目 | 単価（米国東部リージョン） |
|---|---|---|
| Secrets Manager | 保管シークレット数 | $0.40 /シークレット/月 |
| Secrets Manager | APIコール | $0.05 /10,000コール |
| AWS KMS | カスタマー管理キー（CMK） | $1.00 /キー/月（時間按分） |
| AWS KMS | APIリクエスト | $0.03 /10,000リクエスト（フリーティア：月2万リクエスト） |
AWS公式の試算例として、15件のシークレット＋月間10万件のAPIコールを持つWebアプリケーションの場合、Secrets Managerだけで月額約$6〜7程度になります*5。大規模な組織でシークレット数が1万件規模になると月数千ドル規模に達する可能性があるため、シークレット設計段階でのコスト見積もりが重要です。
コスト最適化の3つのアプローチ
- 用途に応じてSecrets Manager/Parameter Storeを使い分ける：ローテーション不要な設定値にはParameter Store（Standardは無料）を使い、Secrets Managerはローテーションが必要な機密情報に絞ります。
- AWSマネージドキー（aws/secretsmanager）を活用する：Secrets Managerのデフォルト暗号化キーはAWSが管理するキーで無料です。カスタマー管理キー（CMK）は追加月額$1/キーが発生するため、規制要件や監査要件がない場合は標準マネージドキーを使う方がコスト効率は高いです。
- 不要シークレットの定期棚卸し：廃止されたサービスのシークレットが残存し続けると、保管料が積み上がります。四半期ごとにシークレットの利用状況を確認し、不要なものを削除することが有効です。なお削除対象のシークレットには課金は発生しません*1。
専任不在時のシークレット管理運用外注の進め方
シークレット管理の運用を内製で回すには、クラウドセキュリティ・IAM設計・IaC・インシデント対応の横断知識が必要です。専任担当者が確保できない場合、外注（アウトソーシング）は現実的な選択肢です。外注を検討する際の進め方を整理します。
外注範囲の明確化：何を任せるかを先に決める
シークレット管理運用の外注範囲は、大きく「設計フェーズ」「構築フェーズ」「保守運用フェーズ」に分けられます。設計・構築だけを外注して運用は内製に移管するケース、常駐または準委任契約でロールを担ってもらうケースなど、自社の体制に合わせて範囲を定義します。
特に「監査ログの確認・異常検知・インシデント対応」は継続的な作業が発生するため、ここを外注するかどうかが契約内容に大きく影響します。外注範囲が曖昧なまま契約すると、インシデント発生時に対応責任が不明瞭になります。
委託先の選定ポイント：AWSパートナーティアを確認する
AWSのパートナーネットワーク（APN）では、AWSの技術審査を通過したパートナー企業がティア別に分類されています。セキュリティ関連サービスの提供実績を持つパートナーか、AWSセキュリティコンピテンシーを保有しているかを確認することが選定の基準の一つになります。
委託先を選ぶ際に確認すべき事項は以下のとおりです。
- AWS Secrets Manager・KMSの構築・運用実績があるか
- IAM設計・ゼロトラスト（境界依存ではなく、すべてのアクセスを継続的に検証するセキュリティモデル）対応の経験を持つか
- インシデント発生時の対応フロー・エスカレーション先が明示されているか
- 監査ログ・コンプライアンスレポートの提供が含まれるか
- SLA（サービスレベルアグリーメント）が明文化されているか
契約形態と引き継ぎ設計を事前に合意する
シークレット管理運用の外注には、準委任契約（業務遂行を委託する形態）が多く使われます。作業内容・成果物・報告頻度を契約時に明確にしておくことで、後々のトラブルを防げます。
外注開始時には「既存シークレットの棚卸し・分類・Secrets Manager移行」が発生することが多く、初期構築に一定の工数が必要です。また、将来的に内製化を目指す場合は「ナレッジ移転計画」を契約に組み込み、運用ドキュメントの整備と担当者教育を外注期間中に並行して進めることが重要です。
内製で対応しようとすると、IAM設計・Terraform実装・ローテーション実装・ログ監視設定に精通したエンジニアが複数名必要になります。専門パートナーに依頼した場合は、初期構築から運用定着まで一貫したノウハウを活用でき、担当者の採用・育成コストを抑えられます。
まとめ：シークレット管理運用の3つの判断軸
本稿では、クラウドのシークレット管理（APIキー・DBパスワード・証明書・トークン）の運用設計のポイントについて整理しました。要点を3つに集約します。
第一に、ハードコードと平文管理はリスクの発生源であり、AWS Secrets Managerへの移行がその解決策になります。マネージドサービスを使うことで、ソースコードに認証情報を持たずに実行時取得できる仕組みが整います。第二に、ローテーション・最小権限・CloudTrail監査ログの3点がシークレット管理運用の核心です。自動ローテーションとIAMの細粒度ポリシーを組み合わせることで、漏洩リスクと被害範囲を継続的に圧縮できます。第三に、コストはシークレット数・APIコール数・KMSキー数で変動します。用途に応じてSecrets Manager/Parameter Storeを使い分け、AWSマネージドキーの活用と不要シークレットの定期棚卸しがコスト最適化の実践的な手順です。
専任担当者の不在がシークレット管理の放置につながるケースは少なくありません。外注を活用してまず基盤を整備し、その過程でナレッジを蓄積して内製化を目指す段階的なアプローチが、多くの組織にとって現実的な進め方です。
よくある質問
AWS Secrets ManagerとKMSは両方使う必要がありますか？
両方を使う必要があるとは限りません。Secrets Managerはデフォルトで「aws/secretsmanager」というAWSマネージドキーを使って無料で暗号化します。カスタマー管理キー（CMK）を作成すると月$1/キーのKMS料金が発生します*5*6。規制要件がなければAWSマネージドキーで十分です。CMKが必要になるのは、監査上「自社でキーを管理している証明が必要」「特定リージョンのキーに限定したい」などの要件がある場合です。
シークレットのローテーション中にアプリケーションが認証エラーになりますか？
適切に設計すれば、ローテーション中に認証エラーは発生しません。AWS Secrets Managerのローテーション処理は、新しいバージョンのシークレットを「AWSPENDING」ステージに保存し、動作確認後に「AWSCURRENT」に昇格させる手順を踏みます*1。アプリケーション側がバージョン番号ではなく「AWSCURRENT」ラベルでシークレットを取得する実装であれば、ローテーション完了後に自動的に新バージョンが使われます。切り替えタイミングでのエラーを防ぐには、古いバージョンも一定期間「AWSPREVIOUS」として保持されるため、切り替え猶予期間を設ける設計が推奨されます。
シークレット管理の外注費用はどのくらいかかりますか？
初期構築費用と月次運用費用で変わります。一次情報として公表されている費用相場はないため、定性的に説明します。初期構築（既存シークレット棚卸し・Secrets Manager移行・IAMポリシー設計・ローテーション実装）はエンジニアの工数に依存します。月次運用（ログ監視・インシデント対応・定期レポート）は準委任契約の稼働量に応じた費用になります。まずRFP（提案依頼書）を複数のAWSパートナーに提示し、見積もりを比較することが現実的な進め方です。
AWS以外のクラウド（Azure/GCP）にも同様のサービスがありますか？
あります。Microsoft Azureでは「Azure Key Vault」がシークレット・鍵・証明書の管理を統合して提供しています。Google Cloud Platform（GCP）では「Secret Manager」がシークレット管理を、「Cloud KMS」が鍵管理を担います。基本的なコンセプト（シークレット保管・暗号化鍵管理・IAM連携・監査ログ）は共通していますが、料金体系・ローテーション方式・マルチクラウド連携の仕組みはサービスごとに異なります。マルチクラウド環境では「HashiCorp Vault」のようなサードパーティ製のシークレット管理ソリューションを採用する選択肢もあります。
小規模スタートアップでもシークレット管理の仕組みを整える必要がありますか？
規模に関わらず、シークレット管理の基本的な仕組みは早期に整えることが推奨されます。IPA「情報セキュリティ10大脅威 2024」でも、設定ミスや内部不正による情報漏洩は組織規模を問わず発生し得る脅威として挙げられています*3。スタートアップで特に問題になるのは「少人数で開発速度を優先するあまり、シークレットをコードにハードコードしたまま成長してしまう」ケースです。Secrets Managerは1シークレット$0.40/月という低コストで使えるため、初期から導入しておくと後からの移行コストを省けます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Amazon Web Services「What is AWS Secrets Manager?（AWS公式ドキュメント）」（2024年）
- *2 出典：OWASP「Secrets Management Cheat Sheet（OWASP Cheat Sheet Series）」
- *3 出典：IPA（情報処理推進機構）「情報セキュリティ10大脅威 2024」（2024年）
- *4 出典：Amazon Web Services「AWS Key Management Service（AWS KMS公式ドキュメント）」（2024年）
- *5 出典：Amazon Web Services「AWS Secrets Manager Pricing（料金ページ）」（確認日：2026年6月）
- *6 出典：Amazon Web Services「AWS KMS Pricing（料金ページ）」（確認日：2026年6月）
