AIエージェントのアイデンティティ管理 — 非人間ID（NHI）の認証・認可・監査を設計する

AIエージェントのアイデンティティ管理とは、AIエージェントを「誰として動くのか」が一意に識別できる主体（非人間ID）として扱い、その認証・認可・監査を一貫して設計・運用する取り組みである。本記事は、AIエージェントを本番運用するエンジニアやセキュリティ担当者に向けて、エージェントが何をしてよいか（認可・最小権限）の手前にある「どのIDとして認証し、そのIDをどうライフサイクル管理するか」に焦点を当てる。読み終えると、非人間ID（NHI）という概念を軸に、ID発行・短命クレデンシャル・委任・失効・監査ログまでを一連の設計として捉え、自分の環境で実装に着手するための見取り図が得られる。

結論から言えば、AIエージェントは「人間のように振る舞うが、人間用IAMの前提を満たさない」存在であり、頻度・寿命・追跡性の3点で従来のID管理が機能しなくなる。 人間用のIDは「1人が1つのアカウントを長期間使い、ログインは1日数回」という前提で設計されている。一方エージェントは大量のリクエストを高速に発行し、数秒で生成・破棄されることもある。本章では、なぜ人間用IAMをそのまま流用すると破綻するのかを、アクセス特性・共有クレデンシャル・認可の限界という3つの観点から整理する。

人間とAIエージェントでは、アクセスの頻度と寿命が桁違いに異なる。人間のユーザーは1日に数回ログインし、セッションは数時間から数日続く程度で、その振る舞いは比較的予測しやすい。これに対してエージェントは、1つのタスクを完了するために短時間で多数のAPI呼び出しを連続して行うことがあり、トラフィックの密度が人間とは比較にならない。

寿命の面でも違いは大きい。たとえばサーバーレス環境やコンテナで動くエージェントは、リクエストごとに起動して処理が終われば消える、といった短命な動き方をすることがある。人間用IDのように「数か月から数年にわたって同じ認証情報を使い続ける」モデルは、こうした使い捨てに近いワークロードには馴染まない。長寿命の固定クレデンシャルを短命なエージェントに割り当てると、エージェント自体は消えても認証情報だけが残り、棚卸しの対象から漏れて放置されやすい。

さらに、エージェントの数は人間の従業員数に縛られない。1人の開発者が複数のエージェントを立ち上げ、それぞれが別のワークロードを担うことも珍しくない。結果として、管理すべきIDの総数が組織の人数を大きく上回り、非人間IDが人間IDより多くなる傾向がある。人数ベースで設計されたID台帳やレビュー運用は、この増加ペースに追従しきれない。頻度・寿命・数という3つの軸で前提が崩れることが、人間用IAMをそのまま当てはめられない根本的な理由である。

複数のエージェントに同じAPIキーやサービスアカウントを共有させる設計は、運用の初期段階では手軽に見える。発行するクレデンシャルが1つで済み、設定もシンプルだからだ。しかしこの手軽さは、追跡不能と漏えい時の被害拡大という形で後から跳ね返ってくる。

たとえば、5つのエージェントが1つの共有キーを使ってデータベースにアクセスしているケースを考える。監査ログには「そのキーがアクセスした」という記録は残るが、「どのエージェントが」その操作を行ったのかは区別できない。問題のある操作が見つかっても、原因となったエージェントを特定できず、調査は手詰まりになりやすい。誰が・何をしたかを後から追えないことは、インシデント対応の遅延に直結する。

漏えいリスクの面でも、共有クレデンシャルは影響範囲を不必要に広げる。1つのキーが万一外部に流出した場合、そのキーを使っていた全エージェントの権限がまとめて攻撃者の手に渡る。1エージェント1IDであれば、流出したIDの権限だけを失効させればよいが、共有設計では「どこまで波及するか」の見極めと封じ込めに時間がかかる。

また、共有クレデンシャルは失効の判断も難しくする。あるエージェントを廃止したくても、同じキーを他のエージェントが使っているとキーを無効化できず、不要な権限が残り続ける。追跡・封じ込め・失効のいずれもが共有によって難しくなることが、エージェントごとに固有IDを発行すべき理由である。

AIエージェントのアクセス制御を語るとき、「何をしてよいか」を定める認可、とりわけ最小権限の設計に関心が集まりやすい。確かに権限を絞ることは重要だが、認可だけでは安全性を担保できない。認可は「あるIDに対して、どの操作を許すか」を決めるルールであり、その前提として「そのリクエストが本当にそのIDから来ているか」を確かめる認証が成立していなければ意味をなさないからだ。

たとえば、あるエージェントに対して「読み取りのみ許可」という最小権限を丁寧に設定したとする。しかし、そのエージェントの認証情報が他のエージェントと共有されていたり、なりすましを許す作りになっていたりすれば、誰がその権限を使っているのかが曖昧になる。権限の範囲を正しく絞っても、その権限を行使する主体が一意に識別できなければ、「適切な相手に適切な権限が割り当たっている」という状態を保証できない。

本記事が認可・最小権限そのものに深入りしないのは、それらが別レイヤーの話だからである。最小権限は「IDに権限を紐づける」段階の設計であり、本記事はその手前、すなわち「どのIDとして認証し、そのIDをどう発行・管理するか」を扱う。認証で主体を一意に確立し、その上に認可を載せるという順序を意識すると、両者の責務が整理される。最小権限の具体的な設計は隣接するテーマとして扱い、ここではIDのライフサイクルに集中する。

非人間アイデンティティ（NHI）とは、人間ではない主体——AIエージェント・サービス・ワークロードなど——に割り当てる、認証・認可・監査の対象となるIDの総称である。 従来「サービスアカウント」や「APIキー」と個別に呼ばれてきたものを、ガバナンスの観点から1つのカテゴリとして捉え直す概念だ。本章では、NHIが具体的に何を対象とするのか、人間IDとどう違い管理上どんな課題があるのか、そしてなぜいま注目されているのかを順に整理する。

NHIが対象とするのは、ログイン画面の向こうにいる人間ではなく、システムの内部で自律的に動く主体である。代表的なものを挙げると、まずAIエージェントがある。ユーザーの指示を受けて外部APIを呼び出したり、データを取得・加工したりする、いわゆるエージェント的なワークロードがこれにあたる。

次にサービスアカウントがある。あるアプリケーションが別のシステムにアクセスするために使う、人間に紐づかない専用のアカウントだ。バッチ処理やスケジュール実行、システム間連携などで広く使われてきた。クラウド環境では、サーバーレス関数やコンテナといったワークロードそのものにIDを与え、IDフェデレーションを通じて他のサービスへアクセスさせる構成も一般的になっている。

このほか、CI/CDパイプライン、外部SaaSと連携するための連携トークン、IoTデバイスなども、人間ではない主体として認証・認可の対象になる。これらはこれまで、APIキー・OAuthクライアント・サービスアカウント・証明書などとして、それぞれ別の文脈で管理されてきた。

NHIという考え方の要点は、これらをバラバラに扱うのではなく、「人間ではない、認証されるべき主体」という共通のカテゴリでまとめて捉えることにある。AIエージェントの普及によって、この非人間の主体が急速に増えつつあり、個別管理では全体像を把握しきれなくなってきた。だからこそ、対象を1つの概念で束ねて統一的に扱う発想が求められている。

NHIと人間IDの最も大きな違いは、IDのライフサイクルを誰が・どうトリガーするかにある。人間のIDは、入社・異動・退職といった人事イベントに連動して発行・変更・削除される。レビューのタイミングも比較的明確で、定期的なアクセス棚卸しの対象として組み込みやすい。一方NHIは、コードのデプロイや新しいエージェントの起動といった技術的なイベントで生まれ、人事プロセスのような決まった節目を持たない。誰がそのIDの「持ち主」なのかが曖昧になりやすい。

管理上の課題は、この曖昧さから生じる。第一に、所有者不明のIDが生まれやすい。あるエンジニアが一時的に作ったサービスアカウントが、本人の異動後も誰にも引き継がれず動き続ける、といった状況は起こりがちだ。誰が責任を持つのか分からないIDは、廃止の判断もできず放置される。

第二に、棚卸しが難しい。人間IDなら「在籍している従業員のリスト」と突き合わせれば不要なIDをあぶり出せるが、NHIには対応する「正解リスト」が存在しないことが多い。どのIDがまだ必要で、どれが不要なのかを判断する材料が乏しい。

第三に、認証方式の多様さがある。人間IDはパスワードや多要素認証といった比較的そろった方式で守られるが、NHIはAPIキー・証明書・トークンなど方式が入り混じり、保護レベルもまちまちになりやすい。こうした違いを踏まえずに人間ID向けの運用をそのまま当てはめると、管理の網からこぼれるIDが生まれる。NHIには、技術イベント起点で所有者と寿命を明示する、専用のガバナンスが要る。

NHIというガバナンスの考え方が注目を集めるようになった背景には、いくつかの構造的な変化がある。最も大きいのは、クラウドネイティブな開発スタイルの広がりだ。マイクロサービス化が進み、システムが多数の小さなコンポーネントに分割されると、それぞれがお互いを認証し合う必要が生まれる。サービス間通信のたびにIDが必要になり、非人間の主体が爆発的に増えた。

そこにAIエージェントの普及が重なった。エージェントは外部のAPIやデータソースに自律的にアクセスして動くため、1つ導入するだけで新たな認証主体が増える。複数のエージェントを連携させる構成では、その数はさらに膨らむ。人間の従業員数とは無関係にIDが増えていくこの傾向が、従来のID台帳や手作業のレビューでは追いきれない規模に達しつつある。

加えて、クレデンシャルの漏えいが現実的な脅威として意識されるようになったことも背景にある。コードリポジトリやログに誤って書き込まれたAPIキー、長期間ローテーションされずに放置されたサービスアカウントのキーなどは、攻撃の足がかりになりやすい。非人間の主体が増えるほど、こうした管理されていないクレデンシャルの総量も増え、攻撃対象領域が広がる。

これらの変化が重なった結果、「人間ではない主体」を個別ではなく一つのカテゴリとして可視化し、所有者・寿命・権限を体系的に管理しようというNHIの発想が現実的な必要性を帯びてきた。いわば、ID管理の対象を人間中心から、人間と非人間の双方へと広げる動きだといえる。

エージェントへの認証情報は、「固有IDを発行し、短命なクレデンシャルで運用し、委任となりすましを制御する」という3つの設計判断で扱う。 鍵となるのは、長期間有効な固定キーをばらまくのではなく、必要なときに必要な範囲だけ短命の認証情報を渡す発想だ。本章では、ID発行から失効までのライフサイクル、短命クレデンシャルとローテーション、そして委任・なりすまし対策という観点から、エージェントに認証情報をどう与えるべきかを掘り下げる。

エージェントのIDは、発行・委任・失効という3つの局面で考えると整理しやすい。まず発行だが、新しいエージェントを立ち上げるとき、それを一意に識別できるIDをひも付けることが出発点になる。このIDは、後から「誰が何をしたか」を追跡する際の基準点になるため、エージェントごとに固有であること、そして所有者（責任を持つ人やチーム）が明示されていることが望ましい。発行の時点で、用途・想定される寿命・必要な権限の範囲をメタデータとして記録しておくと、後の棚卸しが格段に楽になる。

次に委任である。エージェントが単独で完結せず、ユーザーや別のサービスの代理として動く場合、「誰の権限で、どこまでの範囲を代理するのか」を明示する必要がある。委任の範囲を狭く保つことで、仮にそのエージェントが侵害されても、被害が委任された範囲にとどまるよう設計できる。委任は便利な反面、範囲を曖昧にすると権限が連鎖的に広がる危険があるため、明示性が重要になる。

最後に失効だ。エージェントが役目を終えたり、廃止されたりしたとき、対応するIDとクレデンシャルを確実に無効化できなければならない。失効が漏れると、動いていないはずのIDが権限だけを保持したまま残り、攻撃対象として残存する。発行のときに寿命を決めておき、その期限を過ぎたら自動的に失効する仕組みにしておくと、手作業の失効忘れによるリスクを低減できる。発行・委任・失効を一連のライフサイクルとして設計することが、IDの放置を防ぐうえで欠かせない。

固定の長期キーをエージェントに持たせる運用は、漏えい時のリスクを長く抱え込む。キーが流出しても、それが有効である限り攻撃者は使い続けられるからだ。これを避ける基本的な考え方が、短命クレデンシャルである。アクセスのたびに有効期限の短いトークンを発行し、期限が来れば自動的に使えなくなるようにすれば、万一トークンが漏れても悪用できる時間の窓を小さく抑えられる。

短命クレデンシャルは、たとえばOAuth2.0のアクセストークンのように、有効期限付きのトークンを都度取得して使い、期限が切れたら新しいトークンを取り直す、という形で実現されることが多い。ワークロードIDフェデレーションのように、エージェントが置かれた環境そのものを信頼の起点にして、長期キーを保存せずに短命の認証情報を得る仕組みもある。いずれも「秘密を長く保存しない」という方向性は共通している。

それでも長期的な秘密が必要になる場面は残る。その場合に重要なのが、シークレットローテーション、つまり認証情報を定期的に新しいものへ入れ替える運用だ。たとえばシークレット管理ツール（一般にVaultのような仕組み）を使い、エージェントが必要なときにシークレットを取得し、一定期間で自動的に更新する構成にすれば、同じ秘密を長期間使い続けるリスクを下げられる。

短命クレデンシャルとローテーションは、どちらも「秘密が有効な期間を意図的に短くする」という発想で共通している。コードや設定ファイルにキーを直書きするのではなく、実行時に取得して短時間だけ使う設計に寄せることで、漏えいが起きても被害を限定しやすくなる。

委任となりすまし（impersonation）は、エージェントが「自分以外の主体の権限で動く」状況を指す。エージェントがユーザーの代理としてAPIを呼ぶ、あるいは別のサービスとして振る舞う、といったケースだ。これ自体は正当な機能だが、設計を誤ると、本来与えられていない権限をエージェントが行使する抜け道になりかねない。

危険なのは、委任の範囲が曖昧なまま広い権限が引き渡されるパターンである。たとえば、エージェントがユーザーの代理として動くとき、「このユーザーができることなら何でもできる」状態にしてしまうと、エージェントが侵害された場合にユーザーの全権限が攻撃者に渡る。代理できる操作を必要な範囲に絞り、何を代理しているのかをトークンの中に明示しておくことで、被害の連鎖を抑えやすくなる。

なりすましを防ぐうえでは、「誰が誰として動いているか」を認証の段階で検証できることが鍵になる。エージェントが提示するトークンが、本当にそのエージェント自身のために発行されたものか、どの主体の代理として発行されたものかを、受け取る側が確認できる必要がある。OAuth2.0やOpenID Connectといった標準は、トークンに発行対象や用途を含めることで、こうした検証を支える枠組みを提供している。

実装上の指針としては、まず代理の連鎖をできるだけ浅く保つこと。エージェントがさらに別のエージェントへと権限を委任していくと、最終的に誰の権限で何が起きたのかが追えなくなる。次に、委任されたトークンにも短い有効期限を設けること。そして監査ログには「実体としてのエージェント」と「代理している主体」の両方を記録し、後から責任の所在をたどれるようにしておくことが望ましい。

アイデンティティは、最小権限の付与先として、また監査ログの主語として機能してはじめて意味を持つ。 固有IDを発行しても、それが権限の単位やログの記録単位と結びついていなければ、せっかくの識別性が活きない。本章では、認証で確立したIDを最小権限（別レイヤーの話）にどう橋渡しするか、そして「誰が・いつ・何をしたか」を残す監査ログをどう設計するかを扱う。認可の中身そのものには深入りせず、接続点に焦点を当てる。

最小権限（Least Privilege）は、各IDに対して業務上必要な最小限の権限だけを与える原則であり、本記事の主題である認証とは別レイヤーの設計だ。ここで重要なのは、最小権限が成り立つには「権限を割り当てる相手」が一意に確立されていなければならない、という点である。エージェントごとに固有のIDが発行されていれば、そのIDを単位として権限を絞り込める。逆に、複数のエージェントが共有IDを使っていると、片方のエージェントに必要な権限がもう片方にも自動的に付いてしまい、最小権限を貫けない。

つまり、認証によるID確立は、最小権限を実現するための前提条件にあたる。たとえば、データ読み取りだけを行うエージェントと、書き込みも行うエージェントがいるとする。両者に別々のIDが割り当てられていれば、前者には読み取りのみ、後者には読み取りと書き込み、という形で権限を分けられる。IDが分かれていてはじめて、権限も適切に分けられるわけだ。

本記事が最小権限の具体的な設計（ロール定義やポリシー記述の方法など）に踏み込まないのは、それが認可レイヤーの独立したテーマだからである。ここで押さえておきたいのは、「IDを発行して終わり」ではなく、そのIDを権限付与の単位として認可の仕組みに接続する、という橋渡しの発想だ。固有IDという土台があってはじめて、最小権限という上物が安定して載る。認証と認可は責務が異なるが、IDを共通の軸として連携させることで、両者が噛み合う。

監査ログは、「誰が・いつ・何をしたか」を後から再構成できるようにするための記録であり、NHIの設計が実際に機能しているかを確かめる手段でもある。エージェントごとに固有IDを発行する最大の実利の一つは、この監査ログの主語をエージェント単位で特定できるようになることだ。共有IDのままでは「そのIDが操作した」までしか分からないが、固有IDなら「どのエージェントが操作したか」まで残せる。

監査ログに含めておきたい要素を整理すると、まず主体、つまりどのエージェントのIDが操作を行ったかである。委任が絡む場合は、実体としてのエージェントと、代理している元の主体の両方を記録しておくと、責任の所在をたどりやすい。次に時刻、操作が行われた日時だ。さらに対象と操作内容、すなわちどのリソースに対してどんな操作（読み取り・書き込み・削除など）を行ったか。加えて、その操作が成功したか失敗したかという結果も、異常検知の手がかりになる。

これらを記録するうえでの注意点として、ログ自体の保護がある。監査ログが容易に改ざんできる状態では、インシデント時の信頼できる証拠にならない。ログは追記のみで書き換えにくい形で保管し、エージェント自身がそのログを削除・改変できないよう権限を分離しておくことが望ましい。

監査ログは、それ単体ではなく、IDのライフサイクル設計と組み合わせてはじめて価値を発揮する。固有IDの発行・短命クレデンシャル・失効といった仕組みがあるからこそ、ログに残る記録が一貫した主体と結びつき、「誰の責任で何が起きたか」を確からしく語れるようになる。

NHIの実装は、「固有ID発行 → 短命トークンによる権限最小化 → 失効・ローテーションの自動化」という3ステップで段階的に進められる。 いきなり完璧な仕組みを目指す必要はなく、まずIDを分け、次に秘密を短命化し、最後に運用を自動化する、という順序で着実に積み上げるのが現実的だ。本章では各ステップで何をするのか、その狙いとともに具体的に示す。

最初のステップは、エージェントごとに固有のIDを発行することだ。ここがNHI設計の土台になる。共有キーで運用しているなら、まず「1エージェント1ID」の状態に移行することを目指す。各エージェントに、それを一意に識別できる名前やIDを割り当て、どの用途で・誰の責任で動くものなのかをメタデータとして記録しておく。

具体的な進め方としては、たとえば次のような情報をIDごとに整理する。

• ID名（エージェントを一意に識別する名称）
• 所有者（責任を持つ人またはチーム）
• 用途（何のために動くエージェントか）
• 想定される寿命（恒常的か、一時的か）

これらを台帳として持っておくと、後の棚卸しや失効判断の拠り所になる。固有IDがあれば、監査ログにエージェント単位で記録を残せるようになり、「誰が何をしたか」の追跡が可能になる。逆に言えば、このステップを飛ばして共有IDのまま次に進んでも、追跡性は得られない。

このステップで意識したいのは、IDを発行することそのものより、「そのIDに責任者と用途を必ず結びつける」という運用習慣だ。所有者不明のIDを生まないことが、後のNHIスプロール（管理しきれないNHIの増殖）を防ぐ最初の歯止めになる。たとえば、新しいエージェントを立ち上げる手順の中に「ID登録と所有者明記」を組み込んでしまえば、発行漏れや責任者不明のIDが生まれにくくなる。

2つ目のステップは、エージェントに渡す認証情報を短命なトークンに切り替え、権限を時間の面からも最小化することだ。ステップ1で固有IDを確立したら、そのIDに長期キーを直接ひも付けるのではなく、必要なときに短い有効期限のトークンを発行して使う形に寄せていく。

進め方のイメージとしては、まず現状でエージェントが使っている長期キーやハードコードされた認証情報を洗い出す。次に、それらをトークンベースの認証に置き換えられないかを検討する。たとえばOAuth2.0のアクセストークンのように、有効期限付きのトークンを都度取得して使い、期限切れごとに取り直す方式だ。クラウド環境であれば、ワークロードIDフェデレーションのように、エージェントの実行環境を信頼の起点として短命の認証情報を得る構成も選択肢になる。

このステップの狙いは2つある。1つは、漏えい時の被害時間を縮めることだ。トークンの有効期限が短ければ、仮に漏れても悪用できる窓は限られる。もう1つは、秘密をコードや設定に直書きしない文化への移行だ。実行時にトークンを取得する設計にすれば、リポジトリやログにキーが残るリスクそのものを減らせる。

なお、ここで扱うのはあくまで「いつまで・どの認証情報で動けるか」という認証寄りの時間的な最小化であり、「どの操作を許すか」という認可の最小権限とは別レイヤーの話である。両者は補完関係にあるが、まずは認証情報を短命化することで、ID基盤の安全性を底上げできる。

最後のステップは、失効とローテーションを自動化し、人手に依存しない運用へ移すことだ。ステップ1・2で固有IDと短命トークンの土台を作っても、失効やキーの入れ替えが手作業のままだと、対応漏れがそのまま放置リスクになる。自動化の目的は、この「忘れる」「後回しにする」という人的要因を設計で排除することにある。

自動化したい運用を整理すると、おおむね次のようになる。

• 期限切れによる自動失効（発行時に決めた寿命を過ぎたIDやトークンを自動で無効化する）
• 定期的なシークレットローテーション（長期的な秘密が必要な場合に、一定間隔で自動更新する）
• 廃止エージェントのID失効（役目を終えたエージェントのIDを、廃止プロセスと連動して無効化する）

これらを仕組みとして組み込むには、たとえばシークレット管理ツール（Vaultのような仕組み）の自動更新機能を使ったり、IDの発行時に有効期限を設定して期限到来で自動失効させたりする方法がある。重要なのは、失効やローテーションが「誰かが思い出して実行する作業」ではなく、システムが自律的に行う標準動作になっていることだ。

自動化が効いていれば、エージェントが大量に増えても、不要になったIDが権限を保持したまま残り続ける状況を防ぎやすい。逆に、発行は自動化されているのに失効だけ手作業、という非対称な状態は、NHIスプロールを招く典型的な落とし穴である。発行と失効を対称に自動化することが、運用を持続可能にする鍵になる。

NHI設計でつまずきやすいのは、「人間アカウントの流用」と「棚卸し不能なNHIスプロール」という2つの落とし穴である。 どちらも、最初は手軽さや勢いで進めてしまい、後から取り返しがつきにくくなるパターンだ。本章では、これらのよくある設計ミスがなぜ起こるのか、どんな被害につながるのか、そしてどう回避するのかを具体的に見ていく。

最もありがちな落とし穴が、人間用のアカウントをそのままエージェントに使わせてしまうことだ。たとえば、ある開発者が自分のアカウントの認証情報をエージェントに設定し、その権限で外部APIを呼ばせる、といった構成である。手元のアカウントですぐ動かせるため、検証段階では手軽だが、本番運用に持ち込むと複数の問題を抱え込む。

第一に、追跡性が失われる。監査ログにはその開発者のIDで操作が記録されるため、人間本人が行った操作なのか、エージェントが行った操作なのかを区別できない。問題が起きたとき、原因の切り分けが難しくなる。

第二に、権限が過剰になりやすい。人間のアカウントには、その人が業務で使うさまざまな権限がまとまって付いている。エージェントに必要なのはそのごく一部のはずだが、アカウントを流用すると、エージェントに不要な権限まで丸ごと渡ってしまう。万一エージェントが侵害されれば、人間本人の権限すべてが攻撃者に渡るリスクを負う。

第三に、ライフサイクルが噛み合わない。人間のアカウントは退職や異動で無効化されるが、その人のアカウントでエージェントを動かしていると、本人の退職とともにエージェントが突然動かなくなる、という事故も起こりうる。

回避策はシンプルで、エージェントには人間とは別の専用IDを発行することだ。最初は手間に見えても、専用IDにすることで追跡性・最小権限・独立したライフサイクルがすべて成立する。検証段階から専用IDで動かす習慣をつけておくと、本番移行時の手戻りを避けられる。

もう一つの代表的な落とし穴が、NHIスプロール——管理しきれないほどNHIが増殖し、棚卸しが不能になる状態だ。エージェントやサービスアカウントは、人間の採用プロセスのような関門を経ずに、コードのデプロイやちょっとした検証のたびに気軽に作られる。一つひとつは小さな判断でも、積み重なると、誰も全体像を把握していないIDの山ができあがる。

この状態が危険なのは、不要になったIDが見えないまま残り続けるからだ。たとえば、一時的な検証のために作ったサービスアカウントが、検証終了後も削除されずに権限を保持したまま放置される。担当者が異動して所有者が分からなくなると、「消してよいか判断できないから残しておく」という消極的な放置が積み重なる。こうした所有者不明・用途不明のIDは、攻撃者にとって格好の足がかりになる。

NHIスプロールへの対処は、増えること自体を止めるのではなく、増えても管理できる状態を保つことにある。具体的には、IDの発行時に所有者・用途・想定寿命を必ず記録する運用を徹底し、台帳として一元的に把握できるようにする。そのうえで、定期的に台帳を見直し、所有者不明や長期間使われていないIDを洗い出して棚卸しする。発行時のメタデータ記録と定期棚卸しがセットになってはじめて、増殖を管理下に置ける。

さらに有効なのが、前章で触れた失効の自動化との組み合わせだ。発行時に寿命を決めておき、期限を過ぎたら自動で失効する仕組みがあれば、放置されるIDの総量そのものを抑えられる。スプロールは「発行は簡単・失効は手作業」という非対称から生まれるため、両者を対称に設計することが根本的な回避策になる。

Q: 非人間アイデンティティ（NHI）と従来のサービスアカウントは何が違うのですか？ A: 対象とするものは重なりますが、捉え方が異なります。サービスアカウントは個別の仕組みの名前であるのに対し、NHIは「人間ではない、認証・認可・監査の対象となる主体」をサービスアカウント・APIキー・ワークロードIDなどまとめて束ねる上位概念です。バラバラに管理してきた非人間の主体を、所有者・寿命・権限という共通の軸で一元的にガバナンスしようとする発想がNHIの要点です。

Q: 小規模で、エージェントが1つか2つしかなくてもNHIの仕組みは必要ですか？ A: 規模が小さいうちは最小限の対応で十分なことも多いですが、考え方は早めに取り入れておくと後が楽になります。少なくとも、人間アカウントを流用せずエージェント専用のIDを発行し、長期キーの直書きを避けることは、数が少ない段階でも実施する価値があります。エージェントは増えやすいため、最初から専用IDで運用しておくと、増えたときに後から作り直す手戻りを避けられます。

Q: 認証（誰として動くか）と認可（何をしてよいか）は、どちらを先に設計すべきですか？ A: 認証で主体を一意に確立することが先で、認可はその上に載せる、という順序が自然です。誰がリクエストを出しているのかが確定していなければ、最小権限を割り当てる相手も定まらないからです。本記事はこのうち認証・アイデンティティのライフサイクルに焦点を当てており、最小権限などの認可の具体的な設計は別レイヤーのテーマとして扱っています。

Q: 短命トークンを導入すると、トークンの取り直しで処理が複雑になりませんか？ A: 多くの場合、OAuth2.0やワークロードIDフェデレーションなど既存の標準・仕組みがトークンの取得と更新を担うため、アプリケーション側で複雑な処理を自前実装する必要は大きくありません。むしろ、長期キーをコードや設定に直書きする運用のほうが、漏えい対応やローテーションの手間という形で後からコストを生みます。短命トークンは、漏えい時の被害時間を縮めるという安全面の利点が、導入の手間を上回りやすい設計です。