ID:73547さん

スケーラブルなAI-Agent基盤と、AIを用いた攻撃に耐えうるセキュアなアカウント基盤を作る

約8年、認証・認可・アカウント管理の基盤を作ってきました。パスワードからMFA、パスキーへと認証方式は一巡しましたが、いまはAIによる攻撃の自動化、相次ぐ不正アクセス、AIエージェントの登場で、認証・認可の前提そのものが揺らいでいます。キャリアビジョンほどではないですが、今後取り組みたいのは次の3つです。 --- ## 1. 攻撃の主戦場が「認証」から「認証の後」へ移った **課題** AiTMフィッシングや情報窃取型マルウェアは、ログイン後のセッションCookieを奪います。パスキーを導入しても、攻撃者はフォールバック経路へ誘導してきます。クレデンシャルスタッフィングもAIとレジデンシャルプロキシで分散され、IP単位の対策では止まりません。 **やりたいこと（一部） ** - 認証情報を端末の鍵に束縛する（Cookieは **DBSC**、アクセストークンは **DPoP**） - パスキー登録済みのアカウントでは、パスワードやOTPへの **フォールバック** を制限し、使われた場合は高リスクとして扱う - 端末に **デバイストークン** を発行し、未知の端末からのアクセスを識別する - IP・ASN・JA4・HIBP漏洩パスワード照合などを組み合わせた **リスクベース検知**。リスクに応じて通過／追加認証／ブロックを切り替え、ログイン後も IP・ASN・JA4 の変化でセッションを継続的に評価する - 検知結果を受けて追加認証を求める **ステップアップ認証** を、プロダクト横断の共通基盤として提供する --- ## 2. 不正アクセス対策：マイクロサービス同士を無条件に信頼しない **課題** サプライチェーン攻撃や未知の脆弱性（0dayなど）まで考えると、侵入を完全に防ぐことは現実的ではありません。問うべきは **「最前段のWeb Facing サービスが侵害されたとき、大量のユーザー情報まで辿り着けてしまうか」** です。マイクロサービス化し、内部呼び出しにもユーザーを表す内部Sessionを通す構成は珍しくなくなりました。ただ、その検証がすべての内部APIで徹底されているとは限りません。「社内からの呼び出し」を無条件に信頼し、連番のIDで引ける内部APIやgRPCが一つでも残っていれば、攻撃者はIDを前後に変えるだけで全ユーザーの情報を抜けてしまいます。 **やりたいこと（一部）** - **サービス間の認証**：各サービスに短命なワークロードID（SPIFFE など）を発行し、mTLS で相互認証する - **最小権限の認可**：呼び出し元ごとに、呼べるAPI・扱えるデータ・スコープを絞る - **テナント分離の徹底**：内部APIでもリクエストごとに、パラメータではなくユーザーを表す内部JWTでテナント境界を検証し、テナントをまたぐデータ取得を拒否する。仕様上やむを得ずテナントをまたぐ場合も、監視アラートで呼び出しの異常（急な件数増加や想定外の呼び出し元など）を検知する - **外部ID への完全移行**：認可とは別の多層防御として、レガシーなサービス間APIに残る連番のユーザーIDを棚卸しし、推測できないIDへ段階的に置き換える。最終的に、サービス間で連番IDが一切流れない状態にする - --- ## 3. AI-Agent時代の認可：人間以外もIDとして扱う **課題 ** AIエージェントは、人の代理で正規にトークンを使うプログラムです。「人間らしくない挙動＝疑わしい」という、これまでのリスク判定の軸そのものが使えなくなります。 また MCP によって、外部のAIクライアントが直接APIにつながるようになりました。従来の DCR（Dynamic Client Registration）は誰でもクライアントを登録でき、登録内容も自己申告のため、なりすましや大量登録を防ぎにくい仕組みです。 **やりたいこと（一部）** - **クライアント登録**：DCR より安全な CIMDを導入し、AIクライアントの身元をドメインで確かめる - **エージェントID**：エージェントには人間とは別のIDを与え、Non-Human Identity として管理する - **権限委任**：「誰の代理か」をトークンの act クレームで明示し、最小権限のscope・期限付き・即時失効を前提にする - **Human-in-the-Loop**：送金や削除などの重要操作は、CIBA などで本人の承認を得てから実行する - **監査ログ**：エージェントの行動を代理元のユーザーと紐づけ、後から説明できるようにする --- ## まとめ **「誰が、誰の代理で、どこまでの権限を、いつまで持つのか」を、鍵に紐づけて証明できる形にすること。** ユーザーのセッション、サービス間の呼び出し、AIエージェントの委任 ── 対象は違っても、必要なのは同じ設計だと考えています。