AIエージェントと非人間アイデンティティを制御する方法

よく聞かれるのが、次のような声です：

「バックグラウンドで動作しているサービスアカウントやAIエージェントが何百もあります。そのほとんどは自分たちで作成したものではありません。誰が所有しているのかも分かりません。どうやってこれらをセキュアにすればいいのでしょうか？」

今日のあらゆる企業は、ユーザーだけで運営されているわけではありません。舞台裏では、サービスアカウントからAPIトークン、AIエージェントに至るまで、何千もの非人間アイデンティティがシステムにアクセスし、データを移動させ、24時間体制でタスクを実行しています。

これらは新しいものではありません。しかし、急速に増加しています。そして、その多くはセキュリティを考慮して設計されていません。

従来のアイデンティティツールは、意図、コンテキスト、所有権を前提としています。非人間アイデンティティにはそれらがありません。ログインやログアウトもしません。退職処理もありません。そして自律型エージェントの台頭により、彼らはしばしば広範な権限とほとんど監督なしで、自ら意思決定を行い始めています。

すでに新たな盲点が生まれています。しかし、これはまだ始まりに過ぎません。

本記事では、非人間アイデンティティのリスクがどのように進化しているのか、ほとんどの組織がどこに脆弱性を抱えているのか、そしてアイデンティティセキュリティファブリックが、セキュリティチームが規模が手に負えなくなる前に先手を打つためにどのように役立つのかを解説します。

非人間アイデンティティの増加（とリスク）#

クラウドファーストのアーキテクチャはインフラの複雑化を招き、バックグラウンドで動作するアイデンティティの急増を引き起こしました。こうした環境が拡大するにつれ、バックグラウンドアイデンティティの数も増加し、その多くは明確な所有者や監督なしに自動的に作成されます。多くの場合、これらのアイデンティティは人間のユーザーよりも80倍以上も多くなっています。

特にリスクが高いのは、多くのチームがこれらについてほとんど把握していないことです。NHI（非人間アイデンティティ）は、デプロイやプロビジョニングの際に自動的に作成され、その後は追跡も所有もされず、しばしば過剰な権限を持ったまま放置されます。

特にサービスアカウントは至るところに存在します。システム間でデータを移動させ、定期ジョブを実行し、ヘッドレスサービスの認証を行います。しかし、その拡散はほとんど可視化されず、権限の見直しもほとんど行われません。時間が経つにつれ、これらはラテラルムーブメントや権限昇格の格好の手段となります。

しかし、サービスアカウントは全体像の一部に過ぎません。AIの導入が進むにつれ、さらに予測困難なリスクをもたらす新たな非人間アイデンティティのカテゴリが登場しています。

AIエージェントが異なる振る舞いをする理由とその重要性#

ほとんどのマシンアイデンティティと異なり、AIエージェントは自らアクションを起こします。APIとやり取りし、データをクエリし、自律的に意思決定を行います。

この自律性には代償があります。AIエージェントはしばしば機密データやAPIへのアクセスを必要としますが、それに対するガードレールやアクセス取り消しの仕組みを持つ組織はほとんどありません。

さらに悪いことに、多くのAIエージェントは明確な所有者がなく、標準的なライフサイクルもなく、実際の挙動もほとんど可視化されていません。開発者によってデプロイされたり、ツールに組み込まれたり、外部API経由で呼び出されたりします。一度稼働すると、しばしば永続的な認証情報と昇格した権限を持ったまま、無期限に動作し続けます。

また、ユーザーやセッションに紐づいていないため、IPや場所、デバイスコンテキストといった従来のアイデンティティシグナルではAIエージェントの監視は困難です。

見えないアクセスの代償#

シークレットがハードコーディングされ、トークンが使い回され、孤立したアイデンティティが何ヶ月、時には何年もアクティブなまま残ります。

これらのリスクは新しいものではありませんが、数十のサービスアカウントしかなかった時代には静的な認証情報や広範なアクセスも管理可能でした。しかし、何千、何万ものNHIがクラウドサービス全体で独立して動作する現在、手作業での追跡はもはや現実的ではありません。

そのため、多くのセキュリティチームは、そもそもアイデンティティの定義を見直し始めています。なぜなら、AIエージェントが認証し、データにアクセスし、意思決定を行うなら、それ自体がアイデンティティだからです。そして、そのアイデンティティが管理されていなければ、それはリスクとなります。

NHIに共通するセキュリティ課題#

非人間アイデンティティが増大するリスクであると理解することと、そのリスクを管理することは別問題です。根本的な問題は、人間のアイデンティティ管理のために構築されたツールやプロセスが、APIやサービスアカウント、AIエージェントの世界には適用できないことです。このギャップが、多くの組織が直面し始めている、明確かつ危険なセキュリティ課題を生み出しています。

見えないものは守れない#

NHIをセキュアにする上で最も基本的な課題は可視性です。ほとんどのセキュリティチームは、自分たちの環境で動作している全ての非人間アイデンティティの完全なインベントリを持っていません。これらのアイデンティティは、開発者や自動化システムによって、特定の一時的な目的のために動的に作成されることが多いのです。新しいマイクロサービスのサポートや、デプロイスクリプトの実行、サードパーティアプリケーションの統合などのために作られます。

しかし、一度作成されると、中央のアイデンティティ管理システムで文書化されたり追跡されたりすることはほとんどありません。これらは「シャドウ」アイデンティティとなり、アクティブで機能しているにもかかわらず、セキュリティやITからは完全に見えなくなります。どのNHIが存在し、誰（または何）が作成し、何にアクセスしているのかを包括的に把握できなければ、意味のあるセキュリティ戦略を構築することは不可能です。どれだけの攻撃対象領域があるのか分からないまま、守ろうとすることになるのです。

「一度設定して放置」はセキュリティリスク#

開発者や運用チームがよく行うのは、サービスやアプリケーションが途切れなく動作するように、NHIに広範な権限を与えることです。これは、アプリがカメラロールやマイク、位置情報へのアクセスを求めてきたとき、「とりあえず動かすために許可」をタップして、そのまま忘れてしまうのと同じです。

その場では迅速かつ便利ですが、不要なリスクを生み出します。同様に、NHIに過剰な権限を与えることでセットアップは簡単になりますが、重大なセキュリティギャップが生まれ、システムが悪用されやすくなります。

最小権限の原則は、しばしばスピードや利便性のために犠牲にされます。NHIが本来は1つのデータベーステーブルの読み取りだけで良い場合でも、将来の権限エラーを避けるためにデータベース全体への書き込み権限が与えられることがあります。

このアプローチは大きなセキュリティリスクを生みます。過剰な権限を持つアイデンティティは攻撃者にとって高価値なターゲットとなります。もし脅威アクターが過剰な権限を持つNHIを侵害すれば、人間ユーザーの認証情報を使うことなく、システム間を横断し、権限を昇格させ、機密データを持ち出すことができます。

NHIはほとんど見直しや廃止が行われないため、こうした過剰な権限を持つアカウントは何ヶ月、時には何年もアクティブなまま、悪用されるのを待っています。

コンテキストがなければ現代的な制御もできない#

現代のアイデンティティセキュリティはコンテキストに依存しています。ユーザーがログインするとき、位置情報やデバイス、ネットワークなどのシグナルで本人確認ができ、異常があれば多要素認証（MFA）を促すこともできます。NHIにはこうしたコンテキストが一切ありません。単なるサーバー上で実行されるコードです。デバイスも地理的位置も、監視しやすい行動パターンもありません。

静的で長期間有効な認証情報で認証するため、MFAは適用できません。つまり、認証情報が盗まれた場合、それを阻止する第二要素が存在しません。コンテキスト認識型のアクセス制御がないため、正当なNHIの活動と悪意ある活動を区別するのは非常に困難で、気づいたときには手遅れになっていることもあります。

孤立したアイデンティティとデジタルゴースト#

サービスアカウントを作成した開発者が退職したらどうなるでしょうか？特定のAPIトークンを使っていたアプリケーションが廃止された場合は？多くの組織では、関連するNHIがそのまま残されます。こうした「孤立」または「残存」アイデンティティは、権限を保持したまま、ライフサイクルを管理する責任者もいない状態でアクティブです。

これらのデジタルゴーストは、コンプライアンス上の悪夢であり、セキュリティリスクでもあります。環境を混乱させ、正当かつアクティブなアイデンティティの特定を困難にします。さらに重要なのは、放置され監視されていないシステムへの入口となることです。有効な認証情報を持つ孤立したアイデンティティを発見した攻撃者は、誰にも気づかれずに使える完璧なバックドアを手に入れたことになります。

セキュリティチームが制御を取り戻す方法#

拡大し自律化する攻撃対象領域に直面し、先進的なセキュリティチームは受動的な対処から能動的なガバナンスへとシフトしています。その転換は、あらゆる認証情報を持つシステム、スクリプト、エージェントを管理すべきアイデンティティと認識することから始まります。

すべてのNHIを発見しインベントリ化する#

最新のアイデンティティプラットフォームは、AWSやGCP、オンプレミスインフラをスキャンし、隠れたトークン、管理されていないサービスアカウント、過剰な権限を持つロールを可視化できます。

これらのツールは、スプレッドシートや推測に頼るのではなく、人間と非人間の両方のアイデンティティをリアルタイムかつ統合的にインベントリ化します。この基盤がなければ、ガバナンスは単なる当てずっぽうに過ぎません。これがあれば、セキュリティチームはサービスアカウントのもぐらたたきから、本当の制御構築へと進むことができます。

リスクの高いアイデンティティから優先的に対処する#

完全なインベントリが整ったら、次は潜在的な被害範囲を縮小します。すべてのNHIが同じレベルのリスクを持つわけではありません。重要なのは、権限とアクセスに基づいて優先順位をつけて対応することです。リスクベースの権限管理により、危険なほど過剰な権限を持つアイデンティティを特定できます。

そこから、最小権限の原則に沿ってアクセス権を適切に調整していきます。これには、シークレットや認証情報の自動ローテーションなど、より強力な制御の導入も含まれます。自律型AIエージェントのような最も強力なNHIについては、異常な挙動が検知された際に即座にセッションを終了できる「キルスイッチ」の導入が不可欠です。

ガバナンスとライフサイクルの自動化#

人間のアイデンティティにはライフサイクルポリシー（オンボーディング、役割変更、オフボーディング）があります。非人間アイデンティティにも同じ厳格さが必要です。

先進的な組織は、これらのプロセスをエンドツーエンドで自動化しています。新しいNHIが作成されると、所有者が割り当てられ、権限がスコープされ、監査可能なインベントリに追加されます。ツールが廃止されたり開発者が退職した場合、関連するアイデンティティは自動的に廃止され、孤立したアカウントの放置やアクセスの長期残存を防ぎます。

アイデンティティセキュリティファブリックが状況を変える理由#

非人間アイデンティティに関連する多くのリスクは、アイデンティティ自体ではなく、それらを管理しようとする分断されたシステムに起因しています。

各クラウドプロバイダー、CI/CDツール、AIプラットフォームは、それぞれ異なる方法でアイデンティティを扱います。静的トークンを使うものもあれば、デプロイ時に認証情報を発行するものもあり、まったくアクセス期限を設けないものもあります。所有権の定義や権限の割り当て、ガードレールの適用を共通化する仕組みがなければ、拡散は止まりません。

統合されたアイデンティティセキュリティファブリックは、人間と非人間のすべてのアイデンティティを単一のコントロールプレーンで一元管理することで、これを解決します。Oktaの場合、具体的には：

• Identity Security Posture Management（ISPM）によるアイデンティティと態勢ギャップの自動検出
• 機密性の高いシークレットのローテーションやボールト化による最小権限アクセスの適用
• エージェントやサービスアカウントを含むすべてのアイデンティティに対するライフサイクルポリシーの定義
• ワークロードアイデンティティパターン（短命トークン、クライアント認証情報）やアダプティブアクセスをサービスやバックグラウンドジョブに拡張
• AWS IAMが基盤となるエージェント／ワークロード認証情報を発行・強制する一方で、BedrockやAmazon QなどのAWSサービスへのアクセスを統治

場当たり的な回避策を寄せ集めるのではなく、アイデンティティ制御を一度定義すれば、どこにでも適用できます。これにより、盲点が減り、対応速度が上がり、攻撃対象領域が縮小し、しかも10個もの異なるツールを使う必要がなくなります。

NHIを最大の盲点にしないために#

AIエージェントや非人間アイデンティティは、すでにあなたの攻撃対象領域を変化させています。多くのチームが追跡しきれないほど急増し、いまだに明確な所有者や強力な制御、実質的な可視性を持たずに運用されているものが多すぎます。

戦略をゼロから作り直す必要はありません。しかし、確実に非人間アイデンティティを本来あるべきもの、すなわちあらゆるユーザーと同等のガバナンスが必要な重要なアクセスポイントとして扱う必要があります。

統合アイデンティティプラットフォームを使えば、セキュリティチームは稼働中のものをインベントリ化し、スケーラブルな制御を適用し、リスクの高いアクセスを悪用される前に遮断できます。

OktaとAWSが、組織のNHI拡散をどのように整理するかをご覧ください。[ガイドをダウンロード]して今すぐ始めましょう。