- 公開日
APIや外部ツールの権限が必要な範囲に絞られているかは、スコープ名だけでは判断できません。誰の権限で、どの対象に、何を、いつまで実行できるかを承認内容と照合し、再委任と失効も点検します。不一致は縮小や停止へ、確認に必要な資料がない項目は保留へ回し、権限外の要求が実際に拒否されることまで確かめます。
このチェックリストは、接続を有効にする前、権限を変更したとき、利用目的や担当者が変わったときに使う実務上の整理です。各行に「はい」が付けば安全性が保証される認証制度ではありません。サービスごとの仕様、接続先の認可設定、組織が認めた利用条件に合わせて項目を具体化してください。
この記事は、権限を点検するためのチェックリストです。外部APIに渡す権限の考え方は「外部APIを使うAIには、操作・対象・期限を絞った権限を渡す」、適用範囲の決め方は「AIの適用範囲と権限は、対象・操作・利用者で決める」で解説しています。
点検対象と、集める資料を固定する
まず、今回点検する接続を一つ指定します。AIアプリ、接続用のクライアント、仲介サービス、対象API、データの返却先を並べ、どの主体がどの資格情報を使うかを確認します。ここでいう資格情報は、APIキーやアクセストークンなど、アクセスに用いる情報です。点検表には秘密の値を書かず、管理上の識別子と設定の参照先を使います。
必要な資料は、承認された用途と操作一覧、実際の権限設定、資格情報と委任の管理情報、対象サービスの仕様、利用・拒否・失効を確認できる記録です。同じ「設定画面」でも、保存した案なのか、配備済みの設定なのか、実効状態を示す表示なのかで証拠の意味が変わります。取得日時、対象環境、設定版を添えて照合します。
実装の一般原則として、OWASPのAuthorization Cheat Sheetは、最小権限、既定での拒否、要求ごとの権限検証を推奨しています。AIが「許可されています」と説明したことや、画面でボタンが見えないことは、対象APIでの認可が働く証拠にはなりません。操作を受ける位置の設定と記録を確認します。
点検者と設定変更者、承認する人も決めます。小規模なチームで同じ人が複数の役割を担う場合でも、何を確認して、どの変更を許可したかは分けて記録できます。利用開始後の権限縮小で業務が止まる可能性があるなら、停止範囲と代替手段を先に定めます。
四つの判定を同じ意味で使う
「はい」は、確認した資料や試験結果が、その行の命題を裏付ける状態です。「いいえ」は、照合した結果が命題に合わない状態です。「未確認」は、必要な資料や結果がなく、照合を完了できない状態です。「対象外」は、その機能や処理が点検対象に関係しないと確認できる場合だけに使います。
例えば、承認書に「閲覧のみ」と書かれているかは、承認書を読めば判定できます。しかし、実際に更新できないかは、承認書だけでは分かりません。後者を「はい」にするには実効権限や適切な試験などの証拠が必要です。記載の有無と動作の確認を、同じ一行へ押し込まないようにします。
また、資料に再委任の記載がない場合は、「再委任は禁止されている」とも「再委任されていない」とも判断しません。許可条件や実装が未確認なのか、不要であると確認した機能が無効化されているのかを分けます。空欄を「対象外」で埋めると、止めるべき不明点が消えてしまいます。
架空の文書要約連携を点検する
以下は説明用の架空案件です。営業企画部の指定メンバーが、公開用文書領域Aを検索・閲覧し、承認済みAI環境で要約案を作る接続を点検します。要約は利用者へ返すだけで、文書更新、外部送信、別Agentへの処理委任は業務上不要です。
この例では、次の資料が入手できたと仮定します。表の判定はこの架空資料に基づくもので、実際のサービスを検査した結果ではありません。
- 承認記録A：指定グループが接続用主体svc-summaryを使い、文書領域Aを検索・閲覧する用途を許可。利用終了は2026年10月10日18時00分、日本標準時。業務責任者と設定管理者を記載
- 実効設定B：接続用主体はsvc-summary。対象は文書領域A。権限にdoc.readとdoc.writeがあり、別環境の資格情報とは分離。決済・購入機能は接続一覧にない
- 管理資料C：利用者の認証済み主体と、svc-summaryによる接続処理を対応付ける設定があり、秘密の取得先は実行環境に限定。資格情報の有効期限は承認終了時刻と一致
- 不足資料D：自動更新の条件、他Agentへ再委任できるか、既存セッションへの失効反映、権限外試験の結果は入手できていない
doc.read、doc.write、svc-summaryは説明用の識別子で、実在サービスのスコープや仕様を表しません。実務では実際の識別子と、その権限が許す操作を公式仕様で照合します。名称にreadが含まれることだけで、返却データや副作用の範囲が分かるとは限りません。
主体・対象・操作を照合するチェックリスト
最初の表では、資料で確認できる範囲と、不足する実効性確認を分けます。「はい」の行も証拠の範囲を限定しており、接続全体の合格を意味しません。
| 確認する命題 | 確認資料・方法 | この例の判定 | NG・未確認時の対応 |
|---|---|---|---|
| 利用目的、対象者、責任者が承認記録にある | Aを読み、申請対象と一致するか照合 | はい：要約用途と指定グループ等の記載あり | 不足する承認内容を確定するまで有効化を保留 |
| 実行主体が想定した接続用主体である | BとCの主体識別子を照合 | はい：svc-summaryで一致 | 不明な共有主体や別主体を切り分け、必要なものへ変更 |
| 利用者の権限が要求ごとに正しく反映される | Cの設定に加え、本人・別人での認可記録を照合 | 未確認：設定の記載はあるが動作結果を未入手 | 検証環境で主体の対応と拒否を確認するまで保留 |
| 実効設定の対象が承認された文書領域に限定される | AとBの対象条件を照合 | はい：設定上は文書領域A | 全領域などの広すぎる設定を縮小し、範囲外拒否も別途確認 |
| 設定された操作が検索・閲覧だけである | AとBの許可操作を比較 | いいえ：不要なdoc.writeがある | 書込権限を削除し、既存資格情報への反映方法も確認 |
| 本番・検証など別環境の資格情報を共用していない | Bと管理対象一覧を照合 | はい：この例の資料で環境別の分離を確認 | 共用範囲と影響を調べ、用途別に分離して再点検 |
| モデルが秘密の値を取得できない構成になっている | Cとツールのファイル・設定アクセス範囲を照合 | 未確認：取得先の制限は記載されているが、モデル側の経路は未照合 | 秘密管理への読取経路を確認し、過剰なアクセスを閉じる |
| 決済・購入機能の権限が業務条件に合う | 接続一覧と業務目的を確認 | 対象外：この接続には当該機能がない | 追加時に対象へ戻し、個別の金額・承認条件を確認 |
主体の検査では、利用者とサービスアカウントを混同しないことが重要です。サービスアカウントに広い権限があっても、その全権限を利用者が委任したことにはなりません。ログインした利用者が退職・異動で権限を失った後も、接続用主体だけの権限で処理を続けないかを確認します。
OAuthを使う接続では、RFC 9700の2.3節が、アクセストークンの権限を用途に必要な範囲へ制限し、使用先のリソースサーバーを絞ることを推奨しています。スコープは許可される範囲を表す仕組みですが、対象文書やテナントへの制限まで一つのスコープで表せるとは限りません。サービス側の対象条件と併せて確認します。OAuth以外のAPIキーにも同じ設定名があるとは仮定しません。
期限・再委任・失効を点検するチェックリスト
再委任とは、委任を受けたAgentやサービスが、さらに別の主体へ作業や権限を渡すことです。利用者が要約を依頼した事実だけで、別サービスへ資料を転送する許可が生じるわけではありません。今回の用途で必要なのか、どの受信先へ、どの範囲を、いつまで渡せるかを確認します。
| 確認する命題 | 確認資料・方法 | この例の判定 | NG・未確認時の対応 |
|---|---|---|---|
| 承認に終了時刻とタイムゾーンがある | Aの利用期間を照合 | はい：10月10日18時00分JST | 終了条件を責任者が決めるまで期限なしの利用を認めない |
| 資格情報の期限が承認期間を超えない | AとCの日時を同じ時間帯で比較 | はい：記載された期限は一致 | 発行期間を縮め、既存の資格情報が残る期間も確認 |
| 自動更新が承認期間を越えて権限を維持しない | 更新用資格情報と再発行条件を確認 | 未確認：Dの条件未入手 | 自動継続の経路を確認し、期限管理が確定するまで保留 |
| 不要な再委任が実際に無効化されている | 受信先、委任機能、転送・権限設定を確認 | 未確認：業務上不要だが実設定は不明 | 再委任経路を特定して無効化し、その確認まで接続を保留 |
| 必要な場合の再委任が元の対象・操作・期限を越えない | 委任元・受信先・範囲の契約と検証結果を照合 | 対象外：今回の業務では再委任を採用しない | 採用へ変更するなら委任条件を新たに審査する |
| 利用終了や取消後の失効を確認できる | 失効仕様、管理記録、セッションの状態を照合 | 未確認：既存セッションへの反映が不明 | 失効範囲と遅延を確認し、終了済みと報告しない |
| 不要になった権限と所有者不明の接続を見直せる | 見直し担当、利用記録、承認期限を照合 | 未確認：定期見直しの資料未入手 | 担当と頻度を決め、不要分の縮小・廃止を管理 |
| 権限外・期限切れ・取消後の拒否を試験で確認した | 対象版、入力、期待結果、実結果を確認 | 未確認：結果未入手 | 許可された検証環境で確認し、合格まで有効化を保留 |
再委任を業務で使わないという判断と、実装上できないことは別です。このため、上の表では再委任の追加条件を「対象外」にしても、不要な経路を無効化できているかは「未確認」のまま残します。使う予定がないことを、残存機能の点検を省く理由にしません。
期限も二種類あります。業務の利用許可が終わる時刻と、個々のアクセストークンの有効期限です。トークンが短命でも、自動更新の権限が継続すれば、業務上の期限を越えて使える場合があります。逆に期限内でも、本人の権限取消や漏えいへの対応で失効させる必要があるため、期限が来るまで待つ設計にしないようにします。
OAuthの失効を扱うRFC 7009の2.1節は、実装上の失効伝播の遅延や、関連トークンへの影響が方針に依存する点を説明しています。一つのトークンを取り消せば、すべてのセッションや更新用トークンが同時に無効になると決め付けず、対象サービスの仕様を確認します。失効成功を受けたクライアントは、そのトークンを使い続けません。
「いいえ」と「未確認」を、実際の対応へつなぐ
この例は、不要な書込権限が確認され、再委任条件や失効反映も未確認なので、利用開始を保留します。「はい」の数が多いことを理由に通しません。最小化の点検は多数決ではなく、必要な境界が成立しているかを確かめる作業です。
設定管理者はまず、承認された検索・閲覧の機能を残してdoc.writeを取り除く変更案を作ります。既存の資格情報に権限が残る仕様なら、設定の保存だけでは縮小が終わりません。再発行や失効など、対象サービスが必要とする手順を確認し、実効状態に反映します。変更後に閲覧もできなくなった場合は、原因を調べず元の広い権限へ戻さないようにします。
再委任が未確認なら、資料の不足を責任者へ照会します。確認できないまま別Agentへの経路を使ったり、外部APIを直接呼ぶ代替経路へ変更したりしてはいけません。許可対象とデータ経路が変わるためです。確認中に進められるのは、許可されたローカル資料での下書きなど、不明な権限に依存しない作業に限ります。
利用中の接続を止める場合は、停止が必要な範囲、継続中の処理、業務への影響を管理者が確認します。侵害や漏えいが疑われる場合は事故対応手順に従い、通常の変更日程を待つかどうかも責任者が判断します。AIの点検結果だけで本番権限を自動変更する運用にはせず、承認された変更手続へ渡します。
権限外テストは、拒否と正当な処理を対にする
権限を縮小した後は、許可される処理が動くことと、許可されない処理が止まることを対にして確かめます。OWASPのAuthorization Cheat Sheetは、認可ロジックの単体・結合テストを勧めています。ここでは外部へ作用しない検証環境とダミー文書、試験用主体を使う計画を示します。実行済みの結果ではありません。
| 試験条件 | 期待結果 | 確認する証拠 |
|---|---|---|
| 許可された主体が期限内に領域Aを閲覧 | 必要な文書だけ取得できる | 返却内容、主体、対象、設定版 |
| 同じ主体が同じ文書を更新 | 拒否され、文書は変わらない | 認可判定と更新前後の差分 |
| 同じ主体が範囲外のダミー領域Bを閲覧 | 拒否され、本文を返さない | 拒否理由と応答の内容 |
| 別の試験主体が同じ要求を行う | 許可のない主体には返さない | 認証済み主体と認可に用いた主体 |
| 期限切れ・取消済み状態を試験用の認可判定へ与える | 許可しない | 試験用状態と判定結果、実行機能が呼ばれない記録 |
| 再委任を無効化した接続から別Agentへ渡そうとする | 受け渡しを拒否し、資料を転送しない | 委任検証、転送呼出しの有無 |
| 認可情報を取得できない | 許可とみなさず処理を保留または拒否 | 不明状態、応答、データ変更の有無 |
取消後の確認は、失効済みの本番トークンを繰り返し使用する方法ではありません。隔離された試験用の認可実装に状態を与えて検査し、本番では失効記録やサービスが用意する確認機能で反映を追います。試験用状態を与えた検査だけでは、実サービスへの失効伝播を確認したことにはなりません。反映の証拠が揃うまで、実サービスの失効確認は未確認として別に残します。単なる応答待ちを権限拒否と数えず、タイムアウトなどで結果が取れない場合は未確認へ戻します。
表示が「拒否」でも裏側でデータが返っていれば失敗です。反対に範囲外の要求を止めた後、許可済みの閲覧まで常に停止するなら、止める範囲が広すぎる問題として調べます。試験の一部が合格しても、未確認の条件を合格に含めないことが、点検結果の読み違いを防ぎます。
点検記録を更新し続ける
点検の終了記録には、対象接続と環境、設定版、確認日、判定、根拠資料、実施した変更、未確認事項、担当者、次の確認条件を残します。資格情報の値や文書本文を記録へ複製せず、必要な証拠の保管先を参照します。画面の切り抜きを保存する場合も、秘密や関係のない個人情報が写っていないかを確認します。
運用後は、承認された業務に必要な権限が変わっていないかを見直します。AWSのIAMベストプラクティスも、不要なユーザー、ロール、権限、資格情報を定期的に確認して取り除くことを勧めています。ただし、利用記録に現れない操作が必ず不要とは限りません。月末や災害時だけ必要な操作などを業務責任者へ確認し、残す場合は用途と条件を明示します。
見直しのきっかけは、新しいツールの追加、対象データの変更、利用者の異動、接続先や仕様の変更、資格情報の漏えい疑い、例外利用の期限到来などです。すべての接続へ同じ期限や点検間隔を当てはめず、影響と変更頻度に合わせて決めます。管理の負担が大きい場合も、重要な不明点を消して件数を減らすのではなく、承認条件と実効設定を照合しやすい記録に整えます。
権限の最小化は、一度の削除作業では終わりません。必要な処理ができること、不要な処理ができないこと、許可が終わったときに止まることを、それぞれの証拠で確認し続けます。確認できない項目は未確認のまま残し、その権限に依存する利用を進める前に、停止・縮小・追加確認のどれを行うかを決めます。
自分の接続へ適用するときの確認
本表を別の接続へ使うときは、対象サービス、プラン、API・接続仕様の版、管理設定を記録し、機能の提供条件に地域差が関係するかも確認します。公式仕様、利用条件、リリース情報を確認日付きで照合し、使えると確認できない制御を実装済みとして扱わないようにします。AIアプリ、仲介サービス、対象API、返却先を含むデータ経路が変わった場合は、以前の点検結果をそのまま使えません。
点検の結果、必要な操作自体が決まっていないと分かったら、業務要件から権限を設計する段階へ戻します。必要な操作の洗い出しとスコープ・期限・対象の絞り方は「外部APIを使うAIには、操作・対象・期限を絞った権限を渡す」で扱っています。認可をどこで強制するか、Agent間で委任情報をどう検証するかが未確認なら、それぞれの実装担当へ確認を依頼します。チェックリストの記入で設計や実装の不足を埋めたことにせず、何を直せば再点検できるかを具体的に残してください。
セキュリティ業務でAIに渡すログと権限の管理は「セキュリティ業務でAIに渡すログと権限を管理する」で解説しています。
基本から確認する：この記事の前提になる考え方は、「AIエージェントの安全設計（権限・外部資料・承認・検証の基本）」にまとめています。
