【ITニュース解説】Agent identities are the new service accounts

システムエンジニアを目指す初心者の皆さんにとって、将来のキャリアで必ず直面する重要なテーマの一つが、システムのセキュリティと効率的な運用です。特に近年、システムが利用する「サービスアカウント」の管理は複雑さを増しており、AIエージェントの登場によりその課題はさらに深刻化しています。

サービスアカウントとは、人間ではなくシステムやプログラムが、他のサービスやデータにアクセスするために用いる特別なアカウントです。人間のアカウントは、社員の入社・異動・退職といった人事プロセスと連動して管理されるため、比較的状況を把握しやすいですが、サービスアカウントはシステムの数だけ増え、誰が管理しているのか不明になったり、不要になっても権限が残されたままになったりする問題が長年存在していました。AIエージェントは、人間よりもはるかに速いペースで、多くの部門で試験的に導入されるため、従来の管理体制ではその実態を把握しきれなくなっています。

AIエージェントは、自身に与えられたアイデンティティと権限に基づいて動作します。そのため、もしエージェントに不適切な権限が付与されていたり、管理がずさんだったりすると、セキュリティ上の大きなリスクにつながります。記事では、AIエージェントのアイデンティティ管理において、主に三つの問題点が指摘されています。一つは、誰がそのアイデンティティのリストを所有しているのか不明なこと。二つ目は、そのアイデンティティが本当に必要か、付与された権限が適切かを定期的に見直す「再認証」が行われていないこと。そして三つ目は、問題が発生した際に、そのアイデンティティを迅速に停止させ、実際に停止されたことを確認する仕組みがないことです。

これは単なるAIの技術的な問題ではなく、「アイデンティティ管理」に関わる根本的なセキュリティ課題です。例えば、セキュリティ団体OWASPは、AIエージェントにおける脅威として「IDと特権の乱用」を挙げています。これは、エージェントの認証情報が漏洩した場合、意図された範囲を超えて不正な操作を行ってしまう危険性があることを意味します。つまり、AIエージェントが何らかの不正な指示に従ってしまったとしても、その被害の範囲は、エージェントに付与されたアイデンティティの権限によって決まるため、権限管理が非常に重要になります。

具体的な失敗パターンとして、以下のような事例が挙げられます。 まず、「所有者不明でテナント全体に広範な権限を持つアイデンティティ」です。例えば、企業内のすべてのメールボックスに対して読み書きできるような強力な権限を持つアプリケーションがあったとして、その管理者が不明な場合、不正利用されても誰も気づかず、またその権限が本当に必要かどうかの判断もできません。 次に、「CI/CDエージェントが持つ過剰な権限ロール」です。OIDC（OpenID Connect）を使ってCI/CDパイプラインに認証情報を付与するのは良い方法ですが、もしエージェントがAWS環境の全リソースに対して「何でもできる」といった広範な権限を持つロールを引き受けてしまうと、パイプラインに脆弱性があった場合に攻撃者がアカウント全体を乗っ取る危険性があります。 「90日以上更新されていない古い認証情報」も問題です。クライアントシークレットやアクセスキーなどの認証情報が長期間使い回されると、漏洩のリスクが高まります。安全な運用では、一時的な認証情報の利用が推奨され、長期的な認証情報が避けられない場合でも定期的な更新が必須です。 「退職者が所有者だったアイデンティティ」もよく見られます。作成者が退職した後も、そのアイデンティティが有効な権限を持ち続けて動作し、適切な管理がなされないまま放置されることがあります。 GitHubにおける「全リポジトリの管理権限を持つGitHub App」も、広範な権限の例です。リポジトリの設定変更や削除といった強力な操作が可能になるため、最小限の権限付与が強く推奨されます。また、有効期限のない「読み書き可能なデプロイキー」も同様のリスクを抱えます。 さらに、「ロールを停止しても既存のセッションがすぐには終了しない」という問題もあります。例えば、AWSのIAMロールの信頼ポリシーを変更して新しいセッションの開始は阻止できても、既に発行された認証情報やセッションは、有効期限が切れるまで機能し続けてしまうため、緊急時に即座にアクセスを完全に停止できない可能性があります。

これらの課題に対処するためには、AIエージェントに対しても、従来のサービスアカウント管理で培われたセキュリティ対策を適用することが不可欠です。主な管理策は次の通りです。 「棚卸し（Inventory）」として、Microsoft 365、AWS、GitHubなど、利用中のすべての非人間系アイデンティティ（AIエージェントを含む）を一覧化し、現状を正確に把握します。 「所有者（Owner）」を明確にし、すべてのアイデンティティに責任を持つ個人またはチームを割り当てます。所有者不明のアイデンティティはアクセスを許可しないなどの厳格なルールが必要です。 「最小権限（Least privilege）」の原則に基づき、AIエージェントに与える権限は、そのタスクを遂行するために必要な最小限に留めます。 「認証情報の衛生管理（Credential hygiene）」として、可能であれば連携認証やマネージド認証のような安全なメカニズムを利用し、秘密情報を用いる場合は定期的な更新と有効期限の設定、期限切れ認証情報の速やかな削除を徹底します。 「再認証（Recertification）」を定期的に実施し、アイデンティティの必要性と権限の妥当性を確認するプロセスを確立します。 そして、「即時停止機能（An off switch）」を整備します。これは、問題発生時に特定のアイデンティティを無効化し、稼働中のセッションを終了させ、権限と認証情報を削除し、監査ログで停止を確認するまでの一連の手順を事前に定めておくことです。 さらに、「CI/CDにおける変更の検出（Drift in CI）」として、新しいアイデンティティの作成、権限変更、所有者喪失といった予期せぬ変更を自動検出し、承認がない限りデプロイを停止する仕組みを導入することで、リスクを未然に防ぎます。

記事では、これらの管理策を支援する「agent-off-switch (aos)」というツールが紹介されています。このツールは、各クラウドサービスからエクスポートされた設定ファイルを読み込み、オフラインで分析することで、潜在的なリスクを評価し、対応策を提示します。例えば、所有者不明のアイデンティティや広範な権限を持つものなど、危険度の高い問題点をリストアップし、それぞれの停止方法を示す手順書を生成できます。また、過去の状態と比較して、未承認の変更（新しいアイデンティティ、権限変更など）を検出し、CI/CDパイプラインと連携してリスクを低減することも可能です。

ただし、aosツールにも限界があります。再認証プロセスを自動で実行したり、クラウドAPIを直接操作して設定を変更したりする機能はなく、あくまで管理者向けの手順書を生成するに留まります。また、リアルタイム監視ではなく、エクスポートされた時点の情報に基づいているため、常に最新の状態を反映しているわけではありません。さらに、Azureロール割り当てやAWSの権限境界など、すべてのアクセス制限を完全に読み取るわけではないため、提示される危険度スコアが実際のアクセス範囲よりも高く評価される可能性もあります。

システムエンジニアを目指す皆さんにとって、非人間系アイデンティティの適切な管理は、これからのシステム開発と運用において避けて通れない重要なスキルです。まずは、自身が関わる環境の非人間系アイデンティティを棚卸しし、それぞれに所有者を割り当てることから始めるのが良いでしょう。そして、所有者不明のアイデンティティを特定し、それらを安全に停止させる訓練を行うことで、実践的なセキュリティ意識とスキルを身につけることができます。