あなたのクラウドがリスクにさらされているのは、それが高速だからではない。制御の及ばないところで何千もの目に見えないマシンアイデンティティが存続し続けているからだ。
エンジニアリングプロジェクトを率いてきた経験から、私は同じパターンに繰り返し遭遇してきた。私たちはデプロイメント速度に執着する。コミット速度とアップタイムで成功を測定する。しかし、会議室で最も居心地の悪い質問を投げかけるために立ち止まることはほとんどない。それは、私たちが立ち上げたアイデンティティを実際に誰が所有しているのか、という質問だ。
この沈黙は悪意からではなく、構造的なものだ。私たちはソフトウェアデリバリーライフサイクル全体をリソースの作成に最適化してきたが、それらの破棄についてはほとんど経験がない。新しいサービスの「Hello World」を祝福するが、その廃止のための儀式は存在しない。
何年もの間、私はこの不一致が繰り広げられるのを見てきた。私は計画会議に参加し、そこでは数秒で数千のポッドにスケールするシステムを設計していた。しかし、私たちのセキュリティガバナンスモデルは、依然として手動チケット承認の時代に留まっていた。私たちはフェラーリを構築しながら、それを自転車の鍵で保護しようとしていたのだ。
今日の現実は、私たちのインフラストラクチャは根本的に変化したが、アイデンティティガバナンスは変化していないということだ。私たちは依然として幽霊を監査しようとしている。何年も持続するサーバー用に設計されたスプレッドシートを使って、ミリ秒単位で生存するエフェメラルワークロードを保護しようとしている。
私たちが追跡していない静かな爆発
今日、どの現代的企業のダッシュボードを見ても、あなたを夜も眠れなくさせるメトリクスが見つかるだろう。それは従業員数ではない。それは従業員のように振る舞うものの数だ。
人間の開発者一人をオンボーディングするたびに、私たちは意図せず大量のマシンアイデンティティを作成している。サービスアカウント、APIキー、ワークロードトークンがデジタルダストのように蓄積される。調査によれば、非人間アイデンティティは現在、人間を10対1以上の比率で上回っている。
典型的なマイクロサービスのライフサイクルを考えてみよう。開発者のラップトップから本番環境への旅の中で、それは十数個の異なるアイデンティティを生成する可能性がある。リポジトリ用のGitHubトークン、ビルド用のCI/CDサービスアカウント、コンテナをプッシュするためのレジストリ認証情報、そしてデータベース、キュー、ロギングサービスにアクセスするための複数の実行時ロールである。
問題は量だけではなく、不可視性だ。開発者が退職すると、人事部門はオフボーディングプロセスを開始する。メールは遮断され、バッジは機能しなくなる。しかし、3年前にデプロイメントスクリプトにハードコーディングした5つのサービスアカウントはどうだろうか。これらは通常、アクティブなまま、監視されず、誰かがそれらを見つけるのを待っている。多くの場合、これらの「ゾンビアイデンティティ」は、元の目的が消えた後も長い間、管理者権限を保持し続ける。単純に、誰もそれらをオフにする勇気がないからだ。
「テストテナント」の罠
私は、テスト環境は重要ではないと考える罠に陥るチームをあまりにも多く見てきた。「それは単なる開発環境だ」と彼らは言う。「そこには実際の顧客データはない。」この無頓着さは致命的だ。なぜなら、アイデンティティ境界は私たちが考えるほどクリーンではないことが多いからだ。
実際には、テスト環境はしばしば攻撃者が最初に向かう場所だ。それは最も抵抗の少ない道だからだ。私たちはMicrosoft Midnight Blizzard攻撃でこれが実際に起こるのを見た。攻撃者はゼロデイエクスプロイトを使って正面玄関を破壊したわけではなかった。彼らは誰も注意深く監視していなかったレガシーテストテナントを見つけたのだ。
彼らは非人間アイデンティティを侵害し、そのアクセスを使って本番環境の企業メールに直接ピボットした。これらは無害な残り物ではない。開いたバックドアだ。危険性は環境間の関係にある。もし「テスト」CI/CDランナーが「本番」コンテナレジストリにプッシュする権限を持っている場合、または開発者が両方の環境でパスワードを再利用している場合、「テスト」というラベルは誤った安心感に過ぎない。
サプライチェーンの信頼性はアイデンティティの問題である
私たちが信頼するツールについても話す必要がある。Codecovインシデントは、私が知っているすべてのエンジニアリングリーダーの信頼を揺るがした。なぜなら、それはコードの脆弱性ではなく、認証情報の脆弱性だったからだ。
攻撃者はDockerイメージ作成プロセスから認証情報を抽出した。彼らは静的シークレットを使ってBash Uploaderスクリプトを乗っ取った。これにより、彼らはスクリプトをその場で変更することができ、信頼された開発ツールを効果的にデータ流出エンジンに変えることができた。
これが私たちの時代を定義する課題だ。私たちのソフトウェアサプライチェーンは、何千ものAPIキーとシークレットによって結びついている。パイプラインを接続するために長期間有効な静的認証情報に依存し続けるなら、私たちは砂の上に構築している。リポジトリに置かれたすべての静的キー、どんなにプライベートだと思っていても、それは時限爆弾だ。開発者が誤って.envファイルをコミットしたり、侵害されたS3バケットがキングダムへの鍵を公開したりするには、一度だけで十分だ。
AIの加速
静的ボットの管理が溺れているように感じるなら、エージェント型AIの台頭は、あなたに消防ホースを手渡そうとしている。
私たちは、単にチャットするだけでなく、コードを実行するAIエージェントを急いで展開している。これらは、データベースを読み取り、API呼び出しをトリガーできる自律的なワークロードだ。AIエージェントは、事実上、マシンスピードで動作する高度な特権を持つ従業員だ。厳格な指示セットに従う決定論的な従来の自動化スクリプトとは異なり、AIエージェントは確率論的だ。彼らは文脈に基づいて決定を下す。
AIエージェントが「クラウド支出の最適化」を任されていて、広範な権限を持っている場合、それは重要な本番データベースを「使用率が低い」と判断してシャットダウンするかもしれない。または、プロンプトインジェクション攻撃によって騙された場合、機密性の高い顧客データを流出させるように強制される可能性がある。
既存のマイクロサービスのアイデンティティガバナンスを解決していないなら、自律型AIの準備はできていない。攻撃者がAIエージェントを侵害した場合、そのアイデンティティを継承する。そのアイデンティティが「設定が簡単だったから」という理由で広範なアクセス権を持っている場合、あなたは自らのデータ侵害を自動化したことになる。
静的セキュリティの文化的コスト
技術的リスクを超えて、現在のアプローチには深刻な文化的コストがある。アイデンティティガバナンスが遅く、手動で、チケットベースである場合、それはエンジニアリング速度の敵対者となる。
私は、S3バケットへの読み取りアクセスを取得するためだけに、チケットが承認されるのを数日間待つ開発者を見てきた。この摩擦はシャドーITを生む。出荷のプレッシャーを受けている開発者は、公式プロセスをバイパスする。彼らはSlack経由で静的キーを共有したり、アプリに認証情報をハードコーディングしたり、最も抵抗の少ない道だという理由で、すべてに高権限の「管理者」キーを再利用したりする。
逆説的に、重い手のゲートですべてを制御しようとすることで、私たちはより少ない可視性とより少ない制御で終わる。現代のアイデンティティガバナンスの目標は、より頻繁に「ノー」と言うことではなく、セキュアな道を最速の道にすることであるべきだ。
3つの戦略的シフト
これをどう修正するか。図1に示すように、静的レビューから継続的ガバナンスへシフトするフレームワークが必要だ。銀の弾丸はないが、3つのエンジニアリング原則が速度を殺すことなく一貫してリスクを削減する。
Niranjan Kumar Sharma
1. アイデンティティは暗号化されなければならない
IPアローリストへの依存をやめなければならない。動的コンテナの世界では、ネットワークロケーションは信頼性の乏しい代理指標だ。
暗号化アイデンティティに移行する必要がある。すべてのワークロードは、5年間生存するか5ミリ秒生存するかに関わらず、検証可能な証明書を提示しなければならない。SPIFFEのようなフレームワークにより、ワークロードに短命なアイデンティティを自動的に発行できる。これは、接続されているネットワークケーブルではなく、ソフトウェアを信頼することを意味する。このアプローチは、しばしば「ワークロード認証」と呼ばれ、アイデンティティドキュメント(SVID)を発行する前にプロセスを実行しているバイナリを検証する。バイナリが改ざんされている場合、アイデンティティは取得できず、したがってアクセスもできない。
2. 静的認証情報を削除する
静的キーは技術的負債だ。それらはクラウド時代の「付箋に書かれたパスワード」だ。
認証情報の有効期間を積極的に短縮する必要がある。人間がアクセスを必要とする場合、それは一日の終わりに期限切れになるべきだ。マシンがアクセスを必要とする場合、それは数分で期限切れになるべきだ。認証情報が10分間しか機能しない場合、攻撃者にとってのその価値はほぼゼロに低下する。あなたは攻撃の経済性を根本的に変えることになる。
実際には、これはCI/CDパイプラインにOIDC Federationのような標準を採用することを意味する。GitHub Actionsの設定に長期間有効なAWSシークレットを保存する代わりに、ビルドジョブは一時トークンをAWSと交換して、ビルドが終了した瞬間に期限切れになる短命なアクセスを取得すべきだ。このパターンは、AWSやGitHubのようなプロバイダーによって広範囲に文書化されており、「シークレットゼロ」問題を完全に排除する。
3. クリーンアップを自動化する
50,000の権限を手動でレビューすることはできない。数学的に成り立たない。
クリーンアップを自動化するためにクラウドインフラストラクチャエンタイトルメント管理(CIEM)を使用する必要がある。サービスアカウントが過去90日間に実際に使用した権限を調べるツールが必要だ。もし3か月間そのS3バケットに書き込んでいない場合は、権限を自動的に取り消す。「最小権限」を哲学としてではなく、自動化されたガベージコレクションプロセスとして扱う。
この自動化は重要だ。なぜなら、人間は本質的にリスク回避的だからだ。どのエンジニアも、使用されていないと思ったキーを削除してアウトテージを引き起こした人物になりたくない。データ駆動型の自動化はその恐れを取り除き、自信を持って特権を削減することを可能にする。
最終的な考察
私たちが構築するインフラストラクチャはエフェメラルになった。しかし、私たちのマインドセットは依然として静的だ。
過去10年のツールで現代のクラウド環境を管理し続けることはできない。暗号化アイデンティティを採用し、静的シークレットを排除することで、高速かつセキュアなシステムを構築できる。セキュリティの未来は減速することではなく、私たちと同じ速度で動くガードレールを構築することだ。
この記事はFoundry Expert Contributor Networkの一部として公開されています。
参加をご希望ですか?
