企業向けAIのアクセス制御はどうあるべきか？

企業向けAI開発ワークスペースでは、生成された変更をすべて、人間のIDが定義済みのロールを通じ、特定の環境に対して行った操作として扱うべきです。プラットフォームがソースを読み、外部サービスを呼び出し、インフラを作成し、アプリケーションをデプロイし、スナップショットを復元し、コードをエクスポートできるなら、そのアクセスモデルは便利なエディタではなく本番システムを制御しています。

調達で最もよく見かける誤りは、機能一覧にSAML、SCIM、RBACが載っているかだけを確認することです。存在していても、強制されているとは限りません。ベンダーがSAMLアサーションを受け入れながらパスワードログインを有効なままにし、SCIMによる停止を処理しながら有効なセッションを残し、RBACをうたいながら全ビルダーにデプロイ権限を与えることもあります。購入者は、IDプロバイダーから最終的な影響までの連鎖をテストする必要があります。

認証、ライフサイクル管理、認可、承認、認証情報の扱い、環境の分離、監査証跡は、それぞれ異なる問題を解決します。これらを曖昧に「セキュリティ」とひとまとめにすると、管理策の間にある抜け穴が見えなくなります。そこから、退職者のセッションが残ったり、開発エージェントが本番の認証情報に届いたり、承認済みの変更がリリース前に変わったりします。

SAMLで並行した入口をなくす

SAML SSOは、企業のIDプロバイダーをワークスペースへ入る通常かつ強制可能な経路にすべきです。ベンダーのパスワードフォームの横に置く任意のボタンではありません。企業ドメインの所有を確認したら、そのドメインで管理されないIDを作るセルフ登録、パスワード回復、招待を止めるべきです。

OASIS SAML 2.0仕様は、認証と属性に関するアサーションを定義しています。誰かが退職したときにベンダーのアカウントを無効化するものでも、認証済みのエンジニアが本番にデプロイできるかを決めるものでもありません。調達用質問票ではSAMLを集中アクセス制御の証拠として扱いがちですが、SAMLが示すのは認証の一部だけなので、この境界は重要です。

しっかりした実装では、アサーションの署名、発行者、対象者、受信者、時刻条件、リクエストの相関関係を検証します。停止を伴わずに証明書ロールオーバーを行え、不変の識別子でユーザーを対応付けます。メールアドレスは変更、再利用されることがあり、表記だけが違う場合もあるため、主要な識別子には適しません。どのSAML属性が恒久的なアカウントIDになるか、その属性が変わったらどうなるかを確認してください。

管理者がセッション時間、非アクティブ時の制限、重要操作時の再認証を設定できるようにします。ポリシーが多要素認証に依存する場合、ワークスペースはIDプロバイダーの認証コンテキストを尊重すべきです。IDプロバイダーが発行するどのアサーションでも受け入れるなら、SAMLが自動的に強力な認証を提供すると主張すべきではありません。

ローカルの緊急アクセスは、狭い例外にとどめます。IDプロバイダー障害で全管理者が締め出されないよう、通常のSSO経路の外に1つ以上のブレークグラスIDを残します。強力な認証、分離した管理、即時通知、文書化したテスト日程で保護してください。通常の管理者が便利だからという理由でこのアカウントを使ってはいけません。

ログインボタンだけでなく、回避経路をテストします。古い招待を開き、パスワードリセットを申請し、ユーザーのメールアドレスを変更し、許可されたIDプロバイダーグループからユーザーを外し、誤ったテナントへのIDプロバイダー起点ログインを試みます。ゲストドメイン、買収した企業のドメイン、複数のIDプロバイダーをワークスペースがどう扱うか確認してください。ベンダーが曖昧な説明なしにアカウント連携を説明できないなら、重複IDが出ると考えるべきです。

セッションの終了には、独立した受入基準を設けるべきです。IDプロバイダーで人を無効化しても、次のログインを止めるだけで、既存のブラウザセッション、コマンドラインのトークン、エージェントジョブが何時間も続くことがあります。管理者が1つのIDに対する全セッションを失効できるか、SCIMでの停止がその操作を自動的に引き起こすかを尋ねてください。

SCIMで記憶に頼らずアカウントを閉じる

IDソースがユーザーを停止したとき、SCIMは対話型セッション、API認証情報、キュー済み作業、エージェント実行にわたって有効なアクセスを速やかに取り除くべきです。アカウントのフィールドを非アクティブにするだけでは、退職処理は完了しません。

RFC 7643はUserとGroupの基本リソーススキーマを、RFC 7644はそれらのリソースを作成、照会、変更、削除するためのプロトコル操作を定義しています。標準はベンダー間の共通のやり取りを提供しますが、無効化によるローカルの結果をすべて決めるわけではありません。購入者は、変更を受けた後にワークスペースが実際に何をするのかを確認する必要があります。

プロビジョニングでは、初回ログイン前に正しい組織と基本グループメンバーシップでアカウントを作成します。グループ更新は、ワークスペースのロールを予測どおり追加、削除すべきです。停止時には、新規セッションを拒否し、既存セッションと個人トークンを失効し、定期作業を停止または再割り当てし、保留中の承認を停止されたIDで実行できないようにします。削除は顧客の保持ポリシーに従いつつ、監査上の帰属を消してはいけません。

よくある失敗は、リリースグループに所属する契約社員から始まります。IDプロバイダーがその契約社員をグループから外し、SCIMパッチを送ります。ワークスペースでは表示上のロールが更新されても、以前のブラウザセッションにはリリース権限が残っています。削除前に契約社員がキューに入れたデプロイも、後でサービス認証情報によって実行されます。画面上はすべて正しく見えても、有効なアクセスは2か所で生きています。

この失敗は、ディレクトリの状態と実行時の権限の違いを示しています。SCIMが更新するのはディレクトリの状態です。ワークスペースは、その変更をセッション、トークン、ジョブ、承認割り当て、キャッシュされた認可判断へ反映しなければなりません。調達では、即時や自動といった言葉を受け入れるのではなく、想定する失効時間を定めて測定すべきです。

グループの照合もテストが必要です。あるグループからユーザーを外しつつ別のグループには残し、停止と再有効化を行い、グループ名を変更し、本番アクセスを与えるグループを削除します。再有効化しても、ユーザーがもう所属しないグループ由来の権限が復活してはいけません。手動のロール付与はグループ整理後も残り得るため、別に見えるようにします。

SCIMコネクタ自体も確認してください。そのベアラートークンはプロビジョニング権限だけに絞り、ローテーションをサポートし、設定と利用の監査イベントを出すべきです。サービスプロバイダーは有用なエラー応答を返し、安全な再試行に耐える必要があります。グループ変更を黙って捨てるコネクタは、IDチームを無償の監視ソフトにしてしまいます。

RBACで操作をリソースに対応付ける

RBACでは、どのIDが、どのリソースに対し、どの環境で、どの操作を行えるかを表すべきです。広すぎる閲覧者、メンバー、管理者というラベルだけでは、ソフトウェアを構築しリリースするワークスペースを安全に管理できません。

職種名ではなく、操作から始めます。権限カタログでは、プロジェクト閲覧、指示の編集、エージェント実行、生成されたソースの閲覧、ソースのエクスポート、スナップショット管理、バージョン復元、ドメイン設定、デプロイ作成、成果物の昇格、シークレットメタデータ閲覧、認証情報変更、監査記録閲覧、組織ポリシー変更を区別すべきです。プラットフォームごとに用語は違っても、この分離をなくしてはいけません。

実用的な出発点となるマトリクスは次のとおりです。

この表をそのまま採用してはいけません。明示的な判断が必要な組み合わせを見つけるために使ってください。承認者と実行担当を兼ねる組織もあれば、規制の厳しいチームでは分けます。危険なのは、変更を作り、承認し、認証情報を追加し、デプロイし、証拠を削除できる汎用管理者を既定にすることです。

ロールには範囲が必要です。あるエンジニアは1つのワークスペースで開発し、別のワークスペースをレビューし、3つ目にはアクセスできないことがあります。開発にアクセスできるからといって、本番権限を自動で得てはいけません。認可エンジンは、組織、ワークスペース、プロジェクト、環境、リソースの範囲と、文書化された継承をサポートすべきです。親の範囲での許可が下位の拒否を上書きするのか、その逆かを購入者は把握する必要があります。

カスタムロールが役立つのは、ベンダーが安定した権限を公開し、有効なアクセスを報告できる場合だけです。「なぜこのIDはこの操作を行えるのか」という単純な調査に答えられるビューやエクスポートを求めてください。直接割り当て、グループ由来のロール、継承権限、一時的な付与、ポリシー条件が分かる必要があります。この説明がなければ、最初の組織改編後にカスタムロールをレビューするのは難しくなります。

人間のロールとワークロードIDも分けて扱う必要があります。デプロイエージェントが作成者の対話型ロール全体を借りるべきではなく、サービスIDがユーザーインターフェースにログインすべきでもありません。各ワークロードには、名前を持つ所有者、目的、環境、権限セット、有効期限またはレビュー日、失効経路を与えてください。

環境には本当のセキュリティ境界が必要

開発、テスト、本番は、強制される権限、認証情報、実行リソース、データポリシー、リリース経路によって違うべきです。環境セレクターや色付きラベルだけでは、分離は生まれません。

第一の境界は認可です。開発リソースを変更できるビルダーが、同じ継承プロジェクトロールを通じて本番アクセスを得てはいけません。第二は認証情報です。開発エージェントには、開発用データベースとクラウドの権限だけを渡し、すべての環境へ到達できる組織の認証情報を渡してはいけません。第三はデータです。別のプロセスが許可し保護しない限り、プレビューとテストで本番レコードを複製してはいけません。

生成アプリケーションが外部呼び出しやインフラ作成を行える場合、実行環境の分離も重要です。環境ごとに実行ID、ネットワークルール、ストレージ場所、デプロイ先が異なるかを確認してください。共有ワーカーが複数の環境を処理するなら、あるジョブが別のジョブの内容を読まないようプラットフォームがどう防ぐかを確かめます。論理的分離という主張には、アーキテクチャ図ではなく管理策の実演が必要です。

昇格では、より広い本番権限の下で変更可能なソースを再構築するのではなく、レビュー済みの成果物を移動させるべきです。ソースリビジョン、生成ファイル、依存関係のロック状態、テスト結果、ポリシーバージョン、成果物ダイジェストを記録します。本番が最新のプロジェクト状態から再構築する場合、承認後の変更がレビューなしでリリースに入る可能性があります。

スナップショットとロールバックにも同じ境界が必要です。以前のアプリケーションバージョンを復元すると、脆弱なコード、古い設定、データベースと合わなくなったスキーマ前提も復元される可能性があります。本番ロールバックは、認可、証拠、監査証跡を伴う本番操作として扱ってください。ロールバックという安心感のある言葉で、リリースポリシーを回避させてはいけません。

データ所在地と環境分離は関連しますが、別の問題です。選択した国でワークロードを実行することは、保管や転送の要件に対応するかもしれませんが、開発と本番が別のIDやデータを使う証拠にはなりません。調達チームは、所在地に関する主張1つで2つの質問に答えさせず、両方の要件を文書化すべきです。

ベンダーが1つの組織内でこれらの境界を強制できない場合は、別テナントが必要になることがあります。管理の負担が増え、昇格も複雑になるかもしれませんが、プロジェクトラベルに本番権限が閉じ込められているふりをするより安全です。

承認ゲートは重大な境界に置く

承認ゲートは、重大な結果を生む操作を守るべきで、各承認は不変の1つの提案に結び付ける必要があります。エージェントのメッセージごとに承認を求めれば疲弊を招き、曖昧な会話を承認させれば、レビュアーに渡る情報が少なすぎます。

適した対象は、本番デプロイ、認証情報の追加または権限拡大、ネットワーク公開範囲の変更、公開ドメインの設定、機密ソースまたはデータのエクスポート、本番スナップショットの復元、認可ポリシーの変更、監査エクスポートの無効化です。保護されたデータや外部システムに触れない限り、開発中の編集には通常、同じゲートは不要です。

レビュアーには具体的なパケットが必要です。要求された操作、対象環境、ソースと成果物のダイジェスト、ファイルまたはインフラの差分、テスト、ポリシー検出結果、要求する認証情報のスコープ、依頼者ID、エージェントID、有効期限を含めます。承認した場合に何が起きるかを画面に示すべきです。操作境界のない「許可」ボタンは、承認管理策ではありません。

ポリシー自体は、購入者が確認しテストできる形で表せます。

policy_version: 18
rules:
  - action: deploy
    environment: production
    require:
      approvals: 1
      approver_role: release_approver
      requester_cannot_approve: true
      artifact_digest_must_match: true
      expires_minutes: 30
  - action: credential_scope_change
    require:
      approvals: 1
      approver_role: credential_custodian
      scope_diff_required: true

この断片は、よくある2つの失敗を防ぎます。依頼者は自分の本番デプロイを承認できず、成果物が変わればダイジェストが一致しなくなるため承認は無効になります。短い有効期限により、周辺の運用状況が変わった後に古い判断を使うことも防げます。

承認状態は、チャットスレッドやユーザーセッションではなく、操作とともに移動しなければなりません。ソースの編集、対象の変更、権限拡大、認証情報の置き換え、生成の再実行により承認済み提案が変わるなら、新たな判断が必要です。失敗したデプロイの再試行は、成果物と操作が同じで、ポリシーが明示的に許可する場合に限って承認を再利用できます。

キュー済みの操作と自動化された操作にも、同じ強制が必要です。エージェントが承認された時間帯に本番変更を予定し、時間帯終了後に別バージョンを実行できてはいけません。実行サービスは実行時に、認可、承認の有効性、成果物ID、認証情報のスコープを再確認しなければなりません。

計画モードは、意図した作業をレビュアーが理解する助けになりますが、計画は認可境界ではありません。プラットフォームは正確な計画を生成しても、ツール呼び出しが変わったり、連携先が予期しないデータを返したり、モデルが進め方を変えたりして、追加の操作を行うことがあります。影響を起こす操作で承認を強制してください。

本当のインシデントに備え、緊急経路を設けるべきです。理由、限定した期間、制限された操作セット、即時通知、利用後のレビューを必須にします。緊急上書きによって黙って永続的な管理者アクセスが与えられるなら、例外が管理策に取って代わっています。

認証情報は忘れられる前に期限を切る

接続先が対応している場合、ワークスペースは環境と操作のスコープを狭くした一時的なワークロード認証情報を使うべきです。チャット、プロジェクト設定、ビルド変数に置かれた恒久的な組織トークンは、ほとんどのタスクに必要な以上の権限をエージェントに与えます。

3つの概念を分けてください。人間のセッションは誰がワークスペースを使っているかを示します。ワークロードIDは、エージェント、ビルド、デプロイ処理を識別します。シークレットの内容は、そのワークロードが外部システムに到達する権限を与えます。3つすべてで人間の広いトークンを使い回すと、帰属が失われ、失効の影響も大きくなります。

検証済みのワークロードIDを一時トークンに交換する、フェデレーションまたは認証情報ブローカーを優先します。ブローカーは対象者、ロール、環境、時間を制限できます。エージェントプロセスがトークンを受け取るのは、承認済みのツールを呼ぶときだけにし、モデルのコンテキストでシークレット値を見たり再現したりできないようにします。

シークレットを保管するだけでは、スコープの問題は解決しません。完全に暗号化されたクラウド認証情報でも、すべてのアカウントで削除を許すことがあります。金庫だけでなく、接続先の権限をレビューしてください。各認証情報には、所有者、目的、許可環境、許可されたワークロード、作成元、ローテーション方法、最終利用記録を持たせます。

プロンプト、チャット履歴、生成ソース、ログ、スナップショット、サポートバンドル、エクスポートはすべて漏えい経路になり得ます。プラットフォームは永続化前に検出したシークレットをマスクすべきですが、形式は多様でエンコード済みの値も抜けるため、検出は補助的な管理策です。より強い設計では、シークレットの内容をモデル入力や通常の出力経路に決して置きません。

ソースのエクスポートには、意図的なルールが必要です。エクスポートパッケージではシークレット値を除外し、未解決のシークレット参照を示して、受け取るチームが何を設定すべきか分かるようにします。動作する環境ファイルを含むエクスポートは、移植性を認証情報の配布に変えてしまいます。

実権限のないカナリア認証情報で、封じ込めをテストします。識別できる値を各対応入力経路に入れ、エージェントを実行し、スナップショットを作り、ログを確認してプロジェクトをエクスポートします。その後、得られたすべての成果物と監査ストリームを検索します。このテストにより、ベンダーのシークレット境界が直接入力時だけでなく、通常の製品機能でも保たれるかが分かります。

ローテーションと失効は、ワークスペース全体を作り直さずに機能しなければなりません。一時的な認証情報を発行できない接続先をどう扱うか、保管済みシークレットをどうローテーションするか、ジョブが実行時に最新バージョンを取得するかを確認してください。昨日の認証情報を取り込んだジョブは、認証情報レコードが更新されたように見えても続行する可能性があります。

外部連携には独自の同意モデルが必要です。ソースリポジトリ、データベース、チケットシステム、クラウドアカウントを追加するときは、要求するスコープを示し、接続をワークスペースと環境に結び付けるべきです。あるプロジェクトのエージェントの誤りで、すべてのリポジトリやアカウントがさらされないよう、組織全体の接続は例外的にすべきです。

エクスポートした監査ログで意図と結果を再構成する

監査ログでは、ベンダーのユーザーインターフェースに頼らず、人間の依頼を認可、エージェント実行、認証情報の利用、結果としての変更につなげて調査できる必要があります。エクスポート可能とは、管理者だけが手作業でダウンロードできることではなく、顧客が管理するストレージや監視環境へ、文書化され継続する経路があることです。

NIST SP 800-53は、AU-12での監査イベント生成と、AU-9での監査情報保護を分けています。この分離はここでも役立ちます。ワークスペース管理者が唯一のコピーを変更または消去できるなら、デプロイを記録するだけでは不十分です。書き込みを制限し、顧客が保持を管理するワークスペース外へイベントを送ってください。

各イベントには、安定した識別子、タイムスタンプ、テナント、人間の操作者、ワークロードまたはエージェントID、操作、対象リソース、環境、認可判断、ロールまたはポリシー上の根拠、承認の参照、認証情報の参照、結果、相関IDが必要です。変更イベントには、差分、安全な変更前後の値、またはイベントを保管済み成果物に結び付けるハッシュを含めるべきです。

デプロイイベントは、次のような形にできます。

{
  "event_id": "evt_01J...",
  "occurred_at": "2026-07-27T14:03:22Z",
  "actor": {"type": "user", "id": "usr_1842"},
  "workload": {"type": "release_agent", "id": "agt_77"},
  "action": "deployment.create",
  "target": {"environment": "production", "application": "app_91"},
  "authorization": {
    "decision": "allow",
    "policy_version": 18,
    "approval_id": "apr_552"
  },
  "artifact_digest": "sha256:8b1c...",
  "credential_ref": "cred_cloud_prod_4",
  "request_id": "req_9031",
  "result": "success"
}

イベントにはシークレット値ではなく参照を記録します。人間と実行したワークロードの両方を示すため、「エージェントがデプロイした」とだけ書かれた役に立たない記録を避けられます。リクエストIDは、関連するモデル実行、ツール呼び出し、ポリシー判断、接続先の応答をつなげるべきです。

監査とオブザーバビリティは別物です。運用トレースは、エンジニアが遅延、モデル呼び出し、障害をデバッグする助けになります。監査記録は、誰が何をする権限を持ち、何が変わったかを示します。ベンダーは豊富なトレースを提供しながら、ロール変更、シークレット管理、サポートアクセス、エクスポート操作、失敗した認可試行を欠くことがあります。

プロンプト内容は慎重に扱う必要があります。完全なプロンプトにはソースコード、個人データ、シークレットが含まれることがあるため、すべての会話をセキュリティログに保持すると別の機密リポジトリを作ることになります。安定したハッシュ、マスク済みの要約、別途管理されるコンテンツへの参照、実際に生じた操作を記録してください。顧客が保持とマスキングを管理できるようにしつつ、行為をするモデル自身にセキュリティイベントを消す判断をさせてはいけません。

順序、時計の整合性、配信遅延、再試行、重複処理、スキーマ変更、障害時の動作をテストします。エクスポートではバージョニングを文書化し、復旧用のカーソルまたはイベントIDを提供すべきです。顧客の受信側が利用できないとき、ベンダーは開示した上限に従ってイベントをバッファリングし、配信が追い付かないときに報告する必要があります。

サポートアクセスも同じストリームに含めます。ベンダー担当者がテナントにアクセスした時刻、許可した認可、閲覧または変更した内容、アクセス終了時刻を記録してください。顧客がエクスポートできないベンダー内部ログは、企業の調査に答えられません。

調達テストでは管理プレーンを攻める

調達では、隔離した評価用テナントでライブテストを求め、確認された強制を受入証拠として扱うべきです。プレゼンテーションはアーキテクチャを説明できますが、停止されたユーザーからキャッシュ済みのデプロイトークンが失われることまでは証明できません。

IDプロバイダー、SCIMクライアント、複数のテストID、2つの環境、無害な外部認証情報、監査受信側を準備します。実施前に想定結果をベンダーに渡し、発表者の即興力ではなく製品を測る演習にしてください。

1. ローカルパスワード、招待、パスワード回復、重複メール、誤ったIDプロバイダー、停止後の古いセッションという、すべてのID回避経路を試みます。
2. ブラウザセッション、個人トークン、保留中の承認、定期ジョブ、エージェント実行が有効な間に、グループメンバーシップを変更し、特権ユーザーを停止します。
3. 継承ロール、カスタムロール、サービスID、ソースエクスポート、スナップショット復元、開発から本番への移動を通じた権限昇格を試みます。
4. 1つの成果物を承認し、ソースまたは対象を変え、期限切れ承認とより広い認証情報でデプロイを試みます。
5. すべてのイベントをエクスポートし、拒否された試行とベンダーのサポートアクセスを含め、誰が変更を依頼、承認、実行、受領したかを再構成します。

結果ごとに生の証拠を記録します。機密値を除いたSAML応答の詳細、SCIMのリクエストと応答、有効権限のエクスポート、承認ID、成果物ダイジェスト、認証情報メタデータ、監査イベント、タイムスタンプです。スクリーンショットは発見事項の説明に役立ちますが、機械可読な出力の方が、ベンダーが管理策を変えた後に比較しやすくなります。

結果は、合格、不合格、一部対応、予定の4つで記録します。一部対応は、管理策が一部のアクセス経路、リソース、プランでしか動かないことを意味します。予定は、ベンダーが将来の動作を説明した状態です。アカウント担当者がロードマップの日付を示したからといって、どちらも合格に変えてはいけません。

設定を変更した後、失敗したテストをベンダーに繰り返してもらいます。これにより、製品の管理策が欠けているのか、既定値が不適切なだけかを分けられ、管理者が設定を見つけられるかも分かります。文書化されていないサポート作業の奥に隠れたセキュリティ機能は、実際の導入でもまた失敗します。

テスト計画と価格プランの境界を合わせて確認してください。SSOはあるプラン、SCIMは別のプラン、監査エクスポートには別の保持期間または配信上限があるかもしれません。調達に必要なのは、個別に存在する機能の寄せ集めではなく、ポリシーで要求される組み合わせです。各受入基準の横に、プランの利用可否と使用制限を記載します。

管理者の復旧も確認します。最後の組織管理者を削除し、SAML設定を壊し、SCIMトークンを誤ってローテーションし、監査受信側を中断します。ワークスペースは、見えないベンダー回避経路を作らずに、管理された復旧を提供すべきです。復旧操作では、システム内で最も強い監査証拠を生成する必要があります。

Koder.aiを評価する際は、アクセス制御を機能の存在から推測せず、チャットベースの作成フロー、ソースエクスポート、デプロイとホスティング、カスタムドメイン、スナップショット、ロールバック、計画モードを対象に、これらのテストを求めてください。

契約と導入でも管理を保つ

契約と運用プロセスでは、整えられた評価用テナントがなくなった後も、テスト済みの管理策を保つ必要があります。必要な機能、適用プラン、保持期間、配信上限、データの所在地、サポートアクセスのルール、エクスポート形式、互換性のないスキーマ変更の通知、必要な管理策が動かなくなった場合の救済を文書化してください。

セキュリティ文書では、各操作をどちらが担当するかを示すべきです。顧客は通常、IDプロバイダーグループ、ロール割り当て、承認ポリシー、認証情報スコープ、ログの送信先、保持を設定します。ベンダーは、強制、プラットフォーム管理者の管理策、イベント生成、サービス分離、サポートアクセス記録を担います。担当が曖昧だと、インシデント時に予想どおりの穴が生まれます。

認可の意味を変える変更には、通知とレビューを求めてください。新しいエージェントツール、デプロイ先、連携の種類、管理者権限は、顧客側の割り当てが変わらなくても既存ロールを広げる可能性があります。ベンダーは新しい権限を文書化し、広いカスタムロールに黙って含めないようにすべきです。

本番導入は、非本番のID、ポリシー、認証情報交換、承認、監査配信が障害時にも動作してからにします。テスト済みのポリシーバージョンを固定し、権限マトリクスを記録し、アクセスレビューと緊急用アカウントの担当者を決めます。全組織共通の予定表を受け入れるのではなく、組織のリスクと人員の入れ替わりに応じてレビュー間隔を定めてください。

アクセスレビューでは、有効な権限、非アクティブアカウント、グループを回避する直接付与、未使用のワークロードID、古い認証情報、緊急アクセス、失敗した監査配信、サポート活動を確認します。レビュー担当者には、各付与に今も所有者と目的がある証拠が必要です。リソース範囲のないロール名一覧だけの表計算シートでは、その質問に答えられません。

受入条件のうち1つは動かしてはいけません。IDソースが特権ユーザーを停止したとき、利用可能な本番へのすべての経路が合意した時間内に閉じ、エクスポートされたイベントでそれを証明できることです。ワークスペースがこのテストに通らないなら、ほかの管理表は飾りにすぎません。