Azure Key Vault / AWS Secrets Manager でAPIキーを管理する判断軸：ローカル保管の弱点と権限管理への移行設計

APIキーや署名鍵をローカルに置くほど、守るべき対象は増え、管理は難しくなる。
専用の保管サービス（以下「金庫」）に移すと、守るものが「秘密の値そのもの」から「誰が触れるか（権限）」へ変わる。
懸念は消えない。より守りやすい場所へ移動する。それが金庫導入で起きる設計上の変化だ。

手元保管の4弱点

APIキーや認証トークンをローカル（.envファイル・ソースコード・PCのテキストファイル等）に置くことは、直感的には「手元にあるから安全」に見える。構造上は逆だ。

NIST SP 800-204（Security Strategies for Microservices-based Application Systems、2019年）は「トークンのシークレットキーはライブラリコードに含めてはならない。キー値はデータボルトソリューションに保管すべきである」と明記している（出典PDF）。

NSA/CISA「Defending CI/CD Environments」（2023年6月）も「パイプライン内のいかなる箇所でもシークレットをプレーンテキストで渡してはならない」と規定し、IaCテンプレートへのアクセスキーのハードコードをリスク事例として明示している（出典PDF）。

CISA/FBI「Product Security Bad Practices」v2（2025年1月）は「ソースコード内にハードコードされた認証情報は国家安全保障・経済安全保障・公衆衛生に対するリスクを著しく高める」と踏み込んでいる（出典PDF）。

複数の独立した公的ガイドラインが同じ結論に至っている。「ローカルに持つほど弱くなる」は直感と逆だが、構造的に正しい。

金庫が変えること：守る問いの場所が移動する

専用保管サービスを導入すると、秘密の値を日常的に扱う必要がなくなる。代わりに「誰がこの金庫を開けられるか」という権限の管理が日常の守り方になる。

NIST SP 800-57 Part 1 Rev.5（Recommendation for Key Management、2020年5月）は「鍵を暗号境界の外部にプレーンテキスト形式で保管してはならない」原則を規定しており、同文書は鍵のライフサイクル全体（生成・配布・保管・更新・廃棄）を通じた保護要件を定めている（出典PDF）。「廃棄」が含まれている点が重要で、権限（アクセスポリシー）には取り消し・有効期限設定が存在する。ローカルの平文ファイルにそれはない。

守る対象が変わると、何が実現できるか。

• ローカル保管：秘密の値を守る → 値が散らばり追跡・失効が困難
• 専用金庫：金庫を開ける権限を守る → 権限は集中管理でき、取り消し・更新がしやすい

Azure Key Vault はすべての認証済みREST API呼び出しを AuditEvent カテゴリとして記録する（ログ仕様）。AWS Secrets Manager は CloudTrail 経由で GetSecretValue・CreateSecret・DeleteSecret 等の操作を記録する（CloudTrail統合）。「誰がいつ金庫を開けたか」を後から確認できる状態は、ローカル保管では再現できない。

秘密管理とは、守る問いをどこに置くかの選択だ。

ただし、金庫が保護するのは「保管中」と「取り出す瞬間まで（API輸送中）」に限定される。取り出した後のAPIキーの平文（生の値）は金庫の管轄外だ。AWS CloudTrail の仕様も「ログ内にシークレット値は含まれない」と明示している——取り出した後の使われ方は追跡対象ではない。この限界があるからこそ、「人が直接鍵を取り出さない（後述のManaged Identity）」方式が推奨される設計になる。

設計で詰めるチェック3点

金庫を導入した後、以下3点を確認しないと設計が片手落ちになる。

1. 監査ログを有効化したか

Azure Key Vault の AuditEvent ログはデフォルト無効だ。診断設定から手動で有効化しないと「誰がいつ開けたか」が記録されない（設定手順）。

Google Cloud Secret Manager のデータアクセスログ（値の読み取り追跡）も明示的な有効化が必要で、Cloud Logging 料金が発生する（月50 GiB無料、超過 $0.01/GiB）（監査ログ設定）。「金庫に入れたから完全に追跡できる」は、設定完了後のみ正しい。

2. 取り出し操作が記録されているか

AWS CloudTrail では、Read/Write フィルタリング設定の状態によって GetSecretValue（シークレットの実際の読み取り）が捕捉されない場合がある（CloudTrail統合）。Trail 設定後に「GetSecretValue がデータイベントとして記録されているか」を確認すること。

3. 権限の有効期限を設定したか

アクセスポリシーの有効期限は自動では設定されない。期限のない権限は「失効不能」という点でローカル保管の弱点と同じ状態に戻る。Managed Identity を使わずAPI Keyで接続する場合は、鍵のローテーションスケジュールを合わせて設計する。

ローコードツールと専用金庫：管理粒度の違い

n8n・Power Automate 等のローコード基盤は、認証情報を登録するクレデンシャルストアを持っている。「誰が触れるか」を管理するという概念は専用金庫と同じだ。監査ログの粒度と「人が鍵を持たない」接続の対応範囲が異なる。

主要3サービス比較（2025〜2026年時点）

価格出典：Azure Key Vault / AWS Secrets Manager / GCP Secret Manager（価格は変動します。最新情報は各サービスの公式サイトをご確認ください）

ローコードツールの現状（2025年時点）と重要な留保

n8n は Azure Storage・Azure OpenAI 等への接続で Client Secret / API Key ベースのみ公式対応。Azure Key Vault 等の参照接続はAPI Key経由で可能だが、「人が鍵を持たない（Managed Identity：マネージドID）」方式はネイティブ非対応（n8n Azureストレージクレデンシャル）。

Power Automateクラウドフロー は SQL Server・Azure Blob Storage 等の標準コネクタでManaged Identity認証は非対応（クラウドフロー）。Managed Identityが使えるのはDataverseプラグイン向けに限定されている（Power Platform管理者向けドキュメント）。

区別の明示：n8n も Power Automate クラウドフローも「専用金庫（Azure Key Vault等）へAPI Key経由で参照接続する」こと自体は可能だ。「人が鍵を持たない（Managed Identity）」方式に2025年時点で対応していないということであり、金庫利用自体を諦める理由にはならない。

「人が鍵を持たない」が実用段階にある選択肢として、Azure Logic Apps Standard（SQL Server V2・Azure Blob Storage V2・Azure Key Vault 組み込みコネクタ等でManaged Identity対応、公式ドキュメント）とAzure Functions（Extension v5.x以上でAzure Blob Storage・Service Bus・Key Vaultに対応、チュートリアル）がある。

フリーランス・個人開発者としてまず手を動かすなら、GCP Secret Manager の無料枠（バージョン6件/月・アクセス操作10,000回/月）が最小コストの検証起点になる。Azure を使っているなら Key Vault Standard（$0.03/10,000操作）で同等の設計パターンを確認できる。

→ 関連記事：データベース接続でパスワードを共有しない設計

まとめ

専用金庫の導入は、秘密の値を安全な場所に移す手順変更ではなく、守る対象を「秘密そのもの」から「権限」へ移動させる設計変更だ。

次の一歩：まず使っているクラウドの金庫サービス公式ドキュメントを開き、監査ログの有効化手順を確認する。GCP Secret Manager の無料枠（バージョン6件/月）から始めるか、すでに Azure を使っているなら Key Vault の診断設定（AuditEvent）を有効化するのが最初のステップになる。

関連記事：

• データベース接続でパスワードを共有しない設計（鍵を渡さない設計の具体実装）
• Azure OpenAI認証の設計判断（鍵なし接続の実装手順）