1つのAWSキーの漏洩がすべてを変えた！今や、シークレット管理は賢明な選択ではなく、ハイブリッドクラウドの混沌を生き抜くためのサバイバル術だ。
数年前のある朝、同僚が誤ってAWSキーをパブリックなGitHubリポジトリにプッシュしてしまった出来事を、私は決して忘れません。問題が発覚するまで30分もかからず、私たちはすぐに認証情報をローテーションしましたが、それが私たちの目覚めとなりました。
当時、私たちの組織はAWS、Azure、オンプレミスインフラで稼働するワークロードを持つハイブリッドクラウド環境へと拡大していました。シークレットはJenkins、Kubernetes、CI/CDパイプライン、開発者のノートパソコンなどに散在していました。シークレットの保存やアクセス方法を統一するツールやポリシーは存在せず、スプロール（拡散）は現実であり、リスクでもありました。
このインシデントをきっかけに、私たちはシークレット管理に本気で取り組むようになりました。その後、エンタープライズレベルでスケーラブルかつセキュアなシークレット管理を実装するまでの18か月の旅が始まりました。これは私たちがどのようにそれを実現したか、学んだこと、そして同じ道を歩む人に勧めたいことの物語です。また、統一されたシークレット管理システムがなければ、内部統制や規制遵守の監査に失敗しかねない監査ギャップを生み出してしまうことにも気づきました。これは、厳しく規制された業界では許されないことでした。
なぜハイブリッドクラウドはシークレットの問題を拡大させるのか
今日のクラウドネイティブな世界では、開発者は新しいアプリやAPI、サービスを驚くほどの速さで立ち上げます。それぞれがデータベース認証情報やAPIキー、トークンなどの機密情報へのアクセスを必要とし、各クラウドプロバイダーはそれぞれ独自の管理方法を持っています。AWSにはSecrets Manager、AzureにはKey Vault、Kubernetesにはクラスター内の「Secrets」メカニズム（実質的にはbase64エンコードされた設定データ）があります。
この分散モデルは、うまくいっている間は機能しました。しかし、シークレットは環境ごとに重複し、キーはスクリプトにハードコーディングされ、アクセスログは存在しませんでした。ローテーションの統一ポリシーもなく、誤用があった場合のアラートシステムもありませんでした。さらに悪いことに、シークレットがどこに存在し、どれくらいの頻度で更新されているのかを把握できていなかったため、1つの認証情報を無効化するのに何時間もかかり、複数のチームが関与する必要がありました。
GitGuardianの2024年Secrets Sprawlレポートによると、2023年だけで2,300万件のシークレットが公開され、そのうち70％は漏洩後も数か月間有効なままでした。この統計には衝撃を受けました。私たちのセキュリティ体制を変える必要がありました。
最初の決断は、クラウドや環境をまたいでシークレットを統合することでした。私たちには統一されたコントロールプレーンが必要でした。クラウドネイティブツールを評価した結果、マルチクラウド対応、強力なポリシーエンジン、エンタープライズサポートを備えたHashiCorp Vaultを選びました。また、ゼロトラストアーキテクチャと簡単なオンボーディングを特徴とするSaaS型のAkeylessも試験導入しました。どちらも優れた機能を持っていましたが、Vaultを厳格に規制された重要なワークロードに利用することにしました。
統合から得た教訓：アイデンティティ、Kubernetes、CI/CD
シークレット管理ツールの選定は簡単な部分です。エンタープライズ全体に統合するところからが本番です。
まずはアイデンティティから始めました。手動でのユーザー登録は選択肢にありませんでした。VaultをOIDC経由でSSOプラットフォームと統合し、グループを最小権限のVaultポリシーにマッピングしました。マシンにはクラウドネイティブなIAM（AWSロール、AzureマネージドID、Kubernetesサービスアカウント）を利用しました。これらのアイデンティティが新たな信頼レイヤーとなりました。
KubernetesにはVault Agent Injectorを導入しました。これにより、シークレットはプレーンテキストで保存されたり設定にハードコーディングされたりすることなく、実行時にPodへ注入されます。開発者が手動でシークレットを管理する必要はなく、プラットフォームが自動的に処理してくれます。
CI/CDはさらに大きな課題でした。シークレットはGitLab CIの変数やJenkinsの設定、Terraformのステートファイルに埋め込まれていました。パイプラインの各ステージごとにVaultロールを作成し、環境ごとに厳密にスコープを限定しました。ビルドジョブはAppRoleでVaultに認証し、必要なときにシークレットを取得します。また、機密性の高いパイプラインには有効期限付きトークンを発行し、露出のリスクをさらに減らしました。これらの対策はサプライチェーン攻撃から守る上で重要となりました。
その結果、パイプライン内の静的なシークレットを90％以上削減できました。さらに重要なのは、ワークフローに信頼性を組み込めたことです。開発者はルールを破らなくても迅速にリリースできるようになりました。
おまけに、Vaultの監査ログをSIEMに連携させました。これで、すべてのシークレットリクエストが記録され、ユーザーのアイデンティティやシステムの挙動と紐付けて可視化できるようになりました。数か月後、あるサービスアカウントが不正にシークレットへアクセスしていることが発覚したインシデントの際、この可視性が極めて重要となりました。
文化の転換：手動から自動へ、受動からレジリエントへ
シークレット管理は技術的な変革だけでなく、文化的な変革でもあります。初期の段階では、開発者たちは抵抗感を示しました。新しいツールを覚えたくない、アクセスを待ちたくないという声もありました。そこで、私たちは彼らの現状に合わせて対応しました：
- Terraformによる自動オンボーディング
- チームごとに名前空間を管理できるセルフサービスポータル
- ビルド時に環境変数としてシークレットを注入
また、ローテーションをデフォルトとしました。Vaultを使えば、データベースやクラウドプロバイダー向けの短命かつ動的な認証情報を発行できます。一部のシークレットは24時間しか有効ではありません。つまり、万が一漏洩しても影響範囲は小さく抑えられます。
これは単なるセキュリティ対策ではなく、開発者の生産性向上にもつながりました。シークレットの作成・ローテーション・失効が数分で自動的に行えるなら、チームはより速く動けます。
もう一つの教訓は「障害を前提に計画する」ことです。Vaultはクリティカルなサービスです。ダウンすればパイプラインが止まり、アプリがクラッシュし、インフラへのアクセスもできなくなります。私たちはHAモードでVaultを展開し、AWS KMSによる自動アンシールを設定し、定期的に負荷テストを実施しました。「ノイジーネイバー」ワークロードによる度重なる障害を経て、Vault専用のクラスタを用意したことで問題は解決しました。
また、災害復旧用のプレイブックも作成しました。バックアップは暗号化し、四半期ごとにテストしました。シークレットの流出を想定したイベントをシミュレーションし、リアルタイムでトークンを失効させる訓練も行いました。実際にパートナーシステムが侵害された際には、この規律が功を奏し、ローテーションポリシーと失効ワークフローが数分以内に発動しました。
シークレット管理は投資である
データセンターとクラウドにまたがるハイブリッドクラウドの世界では、シークレットは至る所に存在し、攻撃者もそれを知っています。見えないものは守れず、自動化できないものはスケールできません。
私たちの経験から得た最大の教訓はこれです：シークレット管理はセキュリティプロジェクトではなく、プラットフォームへの投資です。アイデンティティ統合を正しく行い、自動化を優先し、最小権限を徹底し、そして何より開発者が正しいことを簡単にできるようにしましょう。
私たちも一朝一夕でここまで来たわけではありません。しかし今では、シークレットは自動でローテーションされ、安全にアクセスされ、継続的に監査され、中央で管理されています。この安心感は、ここに至るまでに費やしたすべての時間に値します。クラウドネイティブアーキテクチャの複雑さが増す中、シークレット管理はサイドカー的なサービスから、エンタープライズセキュリティの基盤となる柱へと進化しなければなりません。
この記事はFoundry Expert Contributor Networkの一部として公開されています。
参加をご希望ですか？
ニュースレターを購読する
編集部からあなたの受信箱へ
下記にメールアドレスを入力してお申し込みください。