誰も所有していないパスワード：マシンを「ゼロスタンディング特権（ZSP）」へ導く

夜間の経理バッチ処理で使われているサービスアカウントの所有者は誰か、インフラ責任者に尋ねてみてください。答えが返ってくるまでに、どれだけ時間がかかるかに注目してほしいのです。私がこれまでに調査した多くの環境では、設定した担当エンジニアは何年も前に退職しており、パスワードはそれ以来ずっとボールト（場合によっては平文の設定ファイル）に置かれたままでした。しかも、現在のチームが誰も加わっていなかった頃に終わった移行作業に合わせた権限が、そのまま残っていることがほとんどです。中身を完全に理解している人がいないため、何かを壊すリスクを冒すより、誰も手を付けずに放置されています。

これをIT環境全体に掛け合わせると、数字はすぐに厄介なものになります。Palo Alto Networksはセキュリティ責任者2,900人以上を対象に2026年版アイデンティティセキュリティ動向調査を実施し、人間のアイデンティティ1件に対して、マシンアイデンティティが平均109件存在することを明らかにしました。

ベンダーごとにアイデンティティの数え方が異なるため、こうした比率は一つだけを鵜呑みにしないほうがよいでしょう。むしろ、同じ調査で示された「特権アクセスの要求の61%に対して、オンデマンドで付与するのではなく、いまだに常時有効な特権（スタンディング特権）で応じている」という結果のほうが、軽視しにくい数字です。 Entro Labsはこうしたアイデンティティの経過年数も調べています。それによると、半数近くが作成から1年以上たっており、7.5%は5年から10年にわたって存在していました。

過去10年間、多くのセキュリティプログラムは、PAM（特権アクセス管理）による人間の管理者の統制に力を注いできました。一方、マシンアカウントにはボールトとローテーションのスケジュールが用意される程度で、私が関わってきたプログラムの大半でも、マシンアカウントへの取り組みはおおむねそこまででした。 

ローテーションは時間を稼ぐだけ

サービスアカウントのパスワードをボールトに格納してローテーションするほうが、スクリプトにハードコードしたままにするよりは優れています。うまく機能しているボールトを撤去するよう勧めるつもりもありません。ただ、ローテーションで変わるのはシークレットだけで、アクセス権限は以前のままです。次の変更までの間、認証情報はすべての権限を保ったまま有効であり、アプリケーションが取得する場所からなら読み取れます。90日周期のうち数日が過ぎた時点で攻撃者がコピーすれば、約3カ月近くにわたって気づかれずに悪用できます。OAuth連携ではさらに状況が悪化します。リフレッシュトークンは、誰も付与したことを覚えていなくなった後も、自らを更新し続けることがあるからです。

2025年8月のSalesloft Driftキャンペーンは、最近の事例として私が挙げられる最も分かりやすい例です。Google Threat Intelligence Groupによると、同グループがUNC6395として追跡する攻撃者は、Drift連携に紐づく窃取したOAuthトークンとリフレッシュトークンを使い、8月8日から18日にかけてSalesforceの顧客インスタンスからデータを抜き出しました。 700を超える組織が巻き込まれています。トークンは本物で、サインインする人間もいなかったため、作動するMFAの確認画面もなく、認証レイヤーが異常に気づく材料もありませんでした。被害を受けた顧客の多くは、そもそも自社内の誰がその連携を承認したのかを答えられなかったのではないか、と私は考えています。

すべてのCIOに、攻撃者が何を狙っていたのかをよく見てほしいと思います。顧客には、SalesforceのレコードからAWSキーやSnowflakeトークンといったシークレットを検索するよう呼びかけられました。サポートケースは、担当者がトラブルシューティング中に認証情報を貼り付けがちな場所だからです。つまり、窃取されたスタンディングトークンが、ほかのシステムにあるスタンディングトークンを探し出すために使われていたのです。その後Salesloftは、 最初の侵入経路を、窃取が始まる数カ月前の3月に起きた同社のGitHubアカウントの侵害と結びつけました。

Ashish Mishra

マシンにとってのゼロスタンディング特権とは

ゼロスタンディング特権では、マシンアイデンティティは待機中、使用可能なアクセス権を一切持ちません。処理を行う必要が生じると、ポリシーエンジンに対して自身を証明し、そのジョブに限定された短命の認証情報を受け取ります。この認証情報は、ジョブが終了すれば自動的に失効します。

人間向けには、すでに似た仕組みをお持ちの方が多いでしょう。通常はPAMプラットフォームを通じたジャストインタイムの権限昇格です。ワークロードの場合は、多くがワークロードアイデンティティ連携によってそこに到達します。ワークロードは、KubernetesクラスターやCIパイプラインなど、接続先がすでに信頼しているプラットフォームの署名付きトークンを提示し、それを一時的なアクセス権と交換します。最も想像しやすいのは、GitHub ActionsからAWSへデプロイするケースです。パイプラインがGitHubにOIDCトークンを要求し、AWSがそのリポジトリに紐づく信頼ポリシーと照合し、ジョブはデフォルトで約1時間有効な認証情報を持つロールで実行されます。この間、アクセスキーがリポジトリに保存されることは一切ありません。Googleの GitHub向け認証アクションも同じ理由から、エクスポートしたサービスアカウントキーよりも連携を推奨しています。そうしたキーは長期間有効であり、パスワードと同じ注意が必要だと警告しています。

本番環境を壊さずに移行するには

すべてのマシンアイデンティティで完全なゼロスタンディング特権を実現することは、現時点ではほとんどの企業で不可能です。取締役会にもその点をはっきり伝えておくべきでしょう。ユーザー名とパスワードでデータベースにログインする旧来のアプリケーションは連携できませんし、静的なAPIキーしか受け付けないベンダー製アプライアンスも数多くあります。実務家の間では、マシンに対する現実的な目標として ニアゼロのスタンディング特権を挙げる声が増えており、私も同じように位置づけています。

すべては棚卸しから始まります。SaaS連携が保持するOAuth権限付与も含め、すべてのマシン認証情報を1カ所にまとめ、それぞれに責任者となる人間の名前を記録する必要があります。所有者欄は事務的な手間に見えるかもしれません。しかし所有者のいないアカウントは、どんな整理作業でも生き残りがちです。無効化を承認する権限を持つ人が誰もいないためです。一覧ができたら、各認証情報で攻撃者が到達できる範囲の大きさ順に並べ替えます。CI/CDパイプラインやクラウド管理者ロールは通常、上位に来ます。しかも連携の仕組みが最も成熟している領域でもあるため、パイプラインのOIDC移行は最初の成果になりやすいと言えます。

連携しているSaaSアプリは、別途見直す価値があります。その多くは何年も前に広範なスコープで承認されており、承認したのもセキュリティ部門ではなく事業部門だったりします。それ以来、誰も見直していません。スコープは、各連携が実際に使っている範囲まで絞り込みましょう。また、自社に代わって保持しているリフレッシュトークンをどう保管しているのか、サプライヤーに尋ねるのも妥当です。Driftの一件を踏まえれば、CRMにアクセスできるベンダーは即答できて当然です。

何年たっても連携できないシステムもあります。その場合でも、許可される操作を変えられないとしても、認証情報の有効期間は短縮できます。ここではボールトが発行するダイナミックシークレットが有効です。データベースアカウントをセッション開始時に作成し、終了時に削除する方式で、アプリケーションの書き換えはほとんど、あるいはまったく必要ありません。

取締役会への報告で私が追跡したい指標は、恒久的に保持されているマシンアクセスの割合に対する、オンデマンドで付与されたマシンアクセスの割合です。最初の数値は芳しくないはずです。それでも早い段階で取締役会に示す価値があります。四半期ごとの変化のほうが、ある時点のスナップショットよりも、進捗をはるかによく伝えるからです。