AI API ゲートウェイの SCIM 主導のチーム制御: ユーザーのプロビジョニング、キーの取り消し、サービス アカウントの実行の維持
SCIM と SSO をライフサイクル入力として使用し、ゲートウェイに明示的なロール、モデル プロファイル、使用権限、キーの所有権、およびサービス アカウント転送ルールを適用させます。目標は、運用アプリケーションを中断することなく、迅速にオフボードすることです。
従業員のオフボードを停止訓練にするべきではありません。多くのチームでは、ID プロバイダーが従業員をすぐに無効にすることができますが、AI API ゲートウェイには依然として、有効期間の長い開発者キー、共有スクリプト、運用サービス アカウント、リセラー テナント、請求特権があり、これらは 1 つの人間のアカウントに明確にマッピングされていません。実際のパターンは、ライフサイクル入力として SCIM を使用し、認可、キーの所有権、使用制限、モデル アクセス、監査レコードを明示的なゲートウェイ オブジェクトとして保持することです。
問題: ID の変更は API 認証と同じではありません
SSO は、ユーザーがサインインできるかどうかを判断します。SCIM は、ユーザーとグループのプロビジョニングの自動化に役立ちます。どちらも単独では、AI ゲートウェイが強制する必要がある運用上のすべての質問に答えることはできません。つまり、このユーザーが管理できるテナントはどれか、どのモデル プロファイルが使用できるか、どのキーが個人用か、どのキーが実稼働を実行するか、誰が予算の増額を承認できるか、どのパートナー API 顧客オブジェクトにアクセスできるかなどです。
クリーンなアーキテクチャでは、ID が完全な認証モデルとしてではなく、ライフサイクル イベントのソースとして扱われます。ゲートウェイは、アイデンティティ プロバイダーからユーザーとグループの変更を受信し、それらを正規化し、ゲートウェイ ネイティブのレコードに変換する必要があります。これらのレコードは、管理アクション、API キーの作成、モデル アクセス、支出制限、サービス アカウントの所有権、監査エクスポートに関して実行時に評価される必要があります。
事実: SCIM 2.0 は、クロスドメイン ID 管理のための IETF 標準プロトコルです。そのプロトコルの動作は RFC 7644 で指定され、そのリソース スキーマは RFC 7643 で指定されます。SCIM は、システム間でユーザーを作成、更新、非アクティブ化、およびグループ化するための標準的な方法をチームに提供します。
推奨事項: ゲートウェイ認証を IdP グループ名またはリクエスト パスの中に直接置かないでください。 SCIM グループを制御されたマッピング テーブルへの入力として使用し、ゲートウェイが所有するレコードからゲートウェイの役割とポリシーを評価します。
ゲートウェイが所有するコア オブジェクト
LLM アクセスはセキュリティ、コスト、運用継続性を兼ね備えているため、ゲートウェイには独自の認証モデルが必要です。少なくとも、これらのレコードをファーストクラス オブジェクトとして定義します。
- アイデンティティ: IdP 件名、電子メール、ステータス、グループ メンバーシップにリンクされた、プロビジョニングされた人間のユーザー。
- テナントまたはワークスペース: ユーザー、キー、予算、モデル プロファイル、統合、および使用状況の管理境界。
- 役割: 開発者、テナント管理者、請求管理者、モデル管理者、監査人、パートナー API 管理者などのゲートウェイ権限
- モデル プロファイル: 許可されたモデル、ルーティング ルール、データ処理制約、機能ゲートのセット
- 予算権限: 支出、制限の引き上げ、高コストのキーの作成、または一時的な例外の承認を行うことができる人
- 人間が所有する API キー: 1 人のユーザーのために作成されたキー。通常、そのユーザーが退職すると取り消されるか一時停止されます。
- サービス アカウント: 所有者、目的、環境、ローテーション メタデータ、最後に使用されたタイムスタンプ、および添付されたポリシーを含むアプリケーション ID
- 監査イベント: ID、役割、キー、予算、認可の決定に関する即時に最小限に抑えられた記録
この分離により、オフボーディングが決定的になります。アプリケーション ID として適切に登録されたサービス アカウントを削除しないと、ユーザーが非アクティブになることがあります。テナント管理者は、基本的な読み取り専用監査アクセスを失うことなく、請求権限を失うことができます。リセラーは、無関係なテナントを列挙することなく、割り当てられた顧客テナントを管理できます。
プロビジョニング フロー: SCIM イベントからゲートウェイ アクセスまで
便利なプロビジョニング フローは、設計上退屈なものです。再試行、部分的な更新、およびグループ同期の遅延を許容する必要があります。 SCIM 実装は、タイミング、削除動作と非アクティブ化動作、属性マッピング、グループ サポートが異なるため、ゲートウェイは脆弱な仮定を避ける必要があります。
1.ユーザーの取り込みと正規化
ゲートウェイが SCIM ユーザーの作成または更新イベントを受信すると、安定した外部識別子を使用して ID レコードを更新/挿入する必要があります。ユーザーのステータス、表示名、電子メール、部門またはコスト センター (利用可能な場合)、および生の IdP グループ参照を正規化された形式で保存します。電子メールを唯一の不変の識別子として使用することは避けてください。メールアドレスが変更されます。
正規化された ID フィールドの例:
{
"external_subject": "idp-user-12345",
"電子メール": "[email protected]",
「アクティブ」: true、
"グループ": ["llm-developers", "support-ai-prod"],
"コストセンター": "サポート",
"last_scim_event_at": "2026-08-30T10:14:00Z"
}2.グループをゲートウェイの役割に変換する
ゲートウェイ管理の変換テーブルを使用します。各行は、IdP グループ参照をテナント、ロール、および許可されたモデルや予算クラスなどのオプションのプロファイルにバインドする必要があります。マップされていないグループには何も許可しないでください。特権マッピングは、特に請求管理者、モデル管理者、テナント所有者、パートナー API 管理者によるレビューが必要です。
{
"idp_group": "サポート-ai-prod",
"テナント": "サポート",
"役割": "開発者",
"model_profile": "サポート承認モデル",
"budget_profile": "標準チーム予算",
"requires_review": false
}推奨事項: マップされていないグループには、default-deny を使用します。文字列がパス プレフィックスと一致したために、誤って運用モデルや請求機関を継承してしまうよりは、新しく作成されたグループが AI アクセスを生成しない方が良いです。
3.効果的なアクセスを実現
グループの変換後、ユーザーの有効なゲートウェイ アクセス (テナント メンバーシップ、ロール、モデル プロファイル、キー作成権限、予算権限、統合権限) を具体化します。実行時チェックでは、リクエストごとに IdP グループ文字列を解析するのではなく、このマテリアライズド ビューまたは一貫性の高い認可サービスを読み取る必要があります。
これにより、管理者は、「サポート テナントでキーを作成できるすべてのユーザーを表示」、「月々の使用制限を引き上げることができるユーザーを表示」、「高コスト推論モデルにアクセスできるすべてのユーザーを表示」など、使用可能なアクセス レビューも可能になります。
ヒューマン キーをサービス アカウントから分離する
最も重要な操作上の区別は単純です。ヒューマン キーは人を表します。サービス アカウントはアプリケーションを表します。両方を汎用 API キーとして扱うと、オフボーディングのリスクが生じます。
人間が所有するキーは、人間のユーザーのライフサイクルを継承する必要があります。ユーザーが非アクティブになると、ゲートウェイは新しいキーの作成をブロックし、個人キーを一時停止または取り消す必要があります。これらのキーには、オフボーディング日の前にチームが誤用を確認できるように、所有者、テナント、モデル プロファイル、予算プロファイル、最後に使用されたタイムスタンプ、目的のメタデータも含まれている必要があります。
サービス アカウント キーは、生産を中断する形で退職する従業員によって所有されるべきではありません。サービス アカウントには、少なくとも 2 人の人間の所有者または所有グループ、環境ラベル、ローテーション ポリシー、最後に使用された可視性、およびポリシー プロファイルが必要です。別の有効な所有者またはブレークグラス プロセスが存在する場合、1 人の所有者が去ってもアクティブなままでなければなりません。
事実: 主要なクラウド ガイダンスでは、一般に、有効期間の長いサービス アカウント キーを管理しないことを推奨し、例外を制限することを推奨しています。同じ原則が AI ゲートウェイ キーにも当てはまります。つまり、アプリケーション ID を明示的に保ち、スコープを設定し、レビューし、ローテーションします。
推奨事項: 個人キーが無人ジョブで使用されている場合は、オフボード中に暗黙的に個人キーを保存しないでください。これを隔離し、誤って分類された本番使用としてフラグを立て、所有権の譲渡を要求し、ポリシーに基づいてサービス アカウント キーに置き換えます。
ステート マシンとしてのプロビジョニング解除の設計
プロビジョニング解除は、単一の削除コマンドではなく、ワークフローである必要があります。ステート マシンは、監査可能性と生産の継続性を維持しながら、リスクを迅速に軽減するのに十分な構造をゲートウェイに提供します。
状態 1: プロビジョニング解除を受信しました
ゲートウェイは、SCIM の非アクティブ化、削除、グループの削除、または同等のライフサイクル イベントを受信します。イベント、そのソース、および以前の有効なアクセスを記録します。 IdP イベントは再試行されたり、順序が狂って到着したりする可能性があるため、このステップを冪等にしてください。
状態 2: ユーザーが非アクティブとマークされている
ゲートウェイ ID を非アクティブに設定します。対話型サインイン、管理者アクション、新しいキーの作成、新しいサービス アカウントの作成、予算の変更をブロックします。これは、低速のクリーンアップ タスクが実行される前に発生するはずです。
状態 3: 個人キーが一時停止されています
人間が所有するキーを直ちに、またはポリシーで定義された短い猶予期間の後に一時停止します。より安全なデフォルトは即時停止です。開発者のエクスペリエンスを考慮して、ゲートウェイは管理者に非アクティブな所有者、キー ID、テナント、および最後に成功した使用方法を示す明確な認証エラーを返すことができます。
状態 4: 所有権の譲渡が必要
非アクティブなユーザーが所有するリソースを検索します: サービス アカウント、テナント、モデル プロファイル、統合、請求先連絡先、パートナー API 資格情報、アラート チャネル。有効な所有グループが存在する場合、所有権は自動的に譲渡されます。それ以外の場合は、リソースを「所有者が必要」キューに入れます。
状態 5: 通知と確認
テナント所有者、セキュリティ管理者、または請求管理者に通知します。通知には、影響を受けるキー、最後に使用されたタイムスタンプ、過去 30 日間および 90 日間の使用状況、新しい所有者が必要なサービス アカウント、最近本番トラフィックを処理した個人キーが含まれる必要があります。
状態 6: 完了
保持ルールで許可されたら、必要な監査レコードを保持しながら、ユーザー属性の削除または匿名化を完了します。 ID ライフサイクル監査では、通常、生のプロンプトは必要ありません。ポリシーの決定、オブジェクト ID、アクター、テナント、タイムスタンプ、結果を説明する、プロンプトを最小限に抑えたイベントを保存します。
モデルのアクセス制限と使用制限は同じレビューに属します
AI ゲートウェイの承認は、誰がエンドポイントを呼び出せるかだけを決めるものではありません。ユーザーは、開発のために低コストのモデルを呼び出すことを許可される場合がありますが、高コストの推論モデル、ホストされたツール、バッチ ジョブ、または運用エイリアスを呼び出すことは許可されません。ユーザーはチームの予算からの支出は許可されますが、予算の増加は承認できません。
有効なロールごとに、関連するコストとモデル権限を定義します。
- 許可されるモデル プロファイルと内部エイリアス。
- リクエストあたりの最大推定コスト
- 月次または日次の予算プロファイル
- 個人キーを作成する権限
- サービス アカウントを作成または所有する権限
- ホストされたツール、ファイル処理、リアルタイム セッション、またはバッチ ワークロードを使用する権限
- 使用状況分析、請求書、コストセンターのエクスポートを表示する権限
推奨事項: ID、ゲートウェイ ロール、アクティブ キー、サービス アカウント、過去 30 日および 90 日間の使用状況、モデル権限、予算権限を結合する 1 つのアクセス レビュー エクスポートを作成します。これは、運用リスクと消費力を合わせて示すため、単純なユーザー リストよりも便利です。
パートナー API とマルチテナント認証
パートナー API の自動化により、別の承認境界が追加されます。代理店、再販業者、またはプラットフォームは、API を介して顧客のテナント、ユーザー、キー、予算、および使用量のエクスポートをプロビジョニングできます。 SCIM 主導の内部ユーザーは、パートナー自身のテナントを管理しているという理由だけで、自動的に広範な顧客オブジェクトへのアクセスを取得すべきではありません。
すべてのパートナー API 操作を呼び出し元と顧客テナントの両方にスコープするようにします。プロビジョニングは冪等である必要があります。同じ顧客テナント、グループ マッピング、またはユーザーを 2 回作成すると、期待される 1 つの状態に収束するはずです。エンドポイントのリストでは、呼び出し元が明示的に管理を許可されているオブジェクトのみを返す必要があります。
オブジェクトレベルおよびオブジェクトプロパティの認可失敗は一般的な API リスクであるため、これは重要です。 AI ゲートウェイでは、テナント レコード、API キー、使用状況台帳、予算、モデル権限、メンバー リスト、サービス アカウントなど、公開されるオブジェクトは機密です。ゲートウェイは、ハッピー パス管理者だけでなく、複数の ID と複数のテナント ID を使用してこれらのパスをテストする必要があります。
役立つテストには次のものがあります。
- テナント A の管理者は、テナント B のキーの読み取り、ローテーション、または取り消しを試みます。
- 停止されたユーザーが古い個人 API キーを試行します。
- 販売パートナー管理者は、所有していない顧客テナントを列挙しようとしています。
- プロジェクト メンバーが請求設定を変更しようとしています。
- サービス アカウント所有者は、自分自身に請求管理者を付与しようとします。
- パートナー API 認証情報が、許可された顧客範囲外でモデル プロファイルを変更しようとします。
迅速な蓄積を行わない監査
ID ライフサイクル調査では通常、誰がアクセスを変更したか、どのポリシーが評価されたか、どのオブジェクトが影響を受けたか、アクションが成功したかどうかを知る必要があります。通常、生のプロンプトは必要ありません。 ID とポリシーの決定のために、別個の監査ストリームを保持します。
次のようなイベントをログに記録します。
- ユーザーがプロビジョニング、更新、非アクティブ化、または削除されました。
- グループはマッピング、マッピング解除、または拒否されました。
- ゲートウェイの役割の付与、変更、または削除。
- 個人キーが作成、一時停止、取り消し、または非アクティブ化後に使用された場合
- サービス アカウントの所有者が変更されました。
- 予算権限の付与または削除
- モデル プロファイルのアタッチまたはデタッチ。
- テナントのスコープによりパートナー API リクエストが拒否されました。
各イベントには、アクター、サブジェクト、テナント、オブジェクト タイプ、オブジェクト ID、ソース システム、決定、理由コード、およびタイムスタンプを含める必要があります。生のプロンプト コンテンツの代わりに安定した ID を使用してください。ペイロードの詳細が必要な場合は、モデル入力ではなく、構造化されたポリシー メタデータを保存します。
実装チェックリスト
AI ゲートウェイに SCIM 主導のチーム制御を実装する場合は、このチェックリストを使用します。
- テナント、ロール、ユーザー、キー、サービス アカウント、モデル プロファイル、予算プロファイル、統合アクセスのゲートウェイ ネイティブ オブジェクトを定義する
- 外部 IdP 件名を電子メールとは別に保存します。
- SCIM ユーザーとグループの更新/挿入を冪等にします。
- デフォルトの拒否動作を備えた、レビュー済みのグループからロールへの変換テーブルを使用します。
- 特権ロールのマッピングには明示的な承認が必要です。
- スキーマと UI で人間が所有するキーとサービス アカウント キーを区別する
- 非アクティブなユーザーのログイン、管理操作、キーの作成、予算の変更をブロックします。
- プロビジョニング解除中に個人キーを一時停止します。
- 非アクティブなユーザーが所有するリソースを転送または隔離する
- サービス アカウントには、所有者のメタデータ、目的、環境、最後に使用されたタイムスタンプ、ローテーションのメタデータが必要です。
- アクセス レビューと使用状況分析および予算権限を連携する
- テナント、顧客、ユーザー、キー、請求オブジェクトにわたるオブジェクト レベルの認可をテストする
- ID 監査レコードはデフォルトでプロンプトを最小限に抑えます。
トレードオフ
SCIM は手動によるアクセス ドリフトを軽減しますが、ゲートウェイ固有の認証の必要性がなくなるわけではありません。 ID プロバイダーが異なれば、グループの同期、削除、非アクティブ化、再試行、および属性マッピングの処理方法も異なります。ゲートウェイは部分的な情報を許容し、安全に収束する必要があります。
個人キーを即時取り消すと、オフボードのリスクが軽減されますが、開発者キーが無人のジョブで使用された場合、運用上の衛生状態が悪化する可能性があります。これは、個人キーを無期限に保存しておく理由にはなりません。これは、個人キーの本番使用を早期に検出し、従業員が退職する前にサービス アカウントに移行する理由になります。
きめ細かいグループ マッピングは正確なガバナンスを表現できますが、グループが多すぎると監査が困難になります。通常、モデル プロファイルや予算プロファイルと組み合わせた、より小規模なゲートウェイ ロールのセットを使用すると、操作が容易になります。
サービス アカウントはアプリケーションを実行し続けますが、所有されなくなったり、過剰な権限が与えられたりする可能性があります。所有者、レビュー日、ローテーション メタデータ、範囲指定されたモデル プロファイル、範囲指定された予算、および最後に使用された分析が必要です。
予測: AI ゲートウェイのアクセス レビューでは、ID、使用状況、支出権限、モデル権限が 1 つのレポートに統合されることが増えています。 「誰がアクセスできるか」「どのキーがまだアクティブであるか」を示さずに「誰がアクセス権を持っているか」を確認することは、本番 AI ワークロードを実行しているチームにとっては浅薄すぎます。
実用的な結論
永続的なパターンは、SCIM と SSO でライフサイクルを推進し、ゲートウェイに独自の認証を許可することです。 ID プロバイダーからユーザーをプロビジョニングし、レビューされたマッピングを通じてグループを変換し、テナントの役割を具体化し、モデルと予算のプロファイルを明示的にバインドし、ヒューマン キーをサービス アカウントとは異なる方法で扱います。
オフボードの場合は、ステート マシンを使用します。つまり、ID イベントの受信、ユーザーを非アクティブとしてマークし、新しいアクセスをブロックし、個人キーを一時停止し、所有リソースを転送または隔離し、所有者に通知し、保持ルールで許可された後に削除を完了します。これにより、セキュリティ チームは迅速に失効でき、プラットフォーム チームは運用を継続できるようになり、財務担当者と監査担当者はモデル、支出、キー、テナントに対する権限を誰が持っていたのか明確な記録が得られます。