社内システムのアクセス権限を棚卸して、不要な権限と申請漏れを洗い出す

処理の起点を決める

毎週土曜の深夜に、定時で一括処理します。 権限の取得は各システムに負荷をかけるため、業務時間を避けます。

ただし、退職者の権限だけは週次では遅すぎます。 人事システムの退職登録をきっかけに、その日のうちに全システムの権限を確認する処理を別に用意してください。退職者のアカウントが残ることは、この業務でもっとも重大なリスクです。

定期巡回は、25本のシステムを四半期で一巡するように分割します。毎週2本ずつ見れば、13週で一巡します。

入力データを集める

権限カタログが、この構成の要です。 FIN_AP_APPROVER_L2 が「買掛金の支払承認（200万円未満）」であることを、どこかに書いておく必要があります。設計書から起こすか、システムの管理者に聞いて作ります。

すべての権限を最初から網羅する必要はありません。特権的なもの（管理者権限、承認権限、マスタ更新権限、個人情報へのアクセス）から作れば、200〜300行で主要な部分が埋まります。

データの取得方法を決める

Entra ID： Microsoft Graph API を使います。ユーザーに付与されたアプリロール割り当ては GET /users/{id}/appRoleAssignments で取得でき、この結果には、そのユーザーが直接メンバーになっているグループを経由して付与されたロール割り当ても含まれます。 グループに対する割り当ては GET /groups/{id}/appRoleAssignments で取れます。

必要な権限は、委任されたアクセスの場合で AppRoleAssignment.ReadWrite.All または Directory.Read.All が最小権限です。 呼び出しに必要な Entra のロールには、ディレクトリ閲覧者、ディレクトリ書き込み者、ID ガバナンス管理者、アプリケーション管理者、クラウド アプリケーション管理者などが挙げられています。棚卸が目的なら読み取りだけで足りるので、書き込み権限を持たない構成にしてください。

SaaS： 提供されていればAPIを、なければ管理画面からのCSVエクスポートを使います。CSVの手動エクスポートが必要なシステムは、週次ではなく月次にするなど、運用に合わせて頻度を分けてください。

基幹システム： 権限テーブルへの読み取り専用接続を用意します。書き込み権限を持たせないでください。

最終利用日： 各システムのログから取ります。取得できないシステムは「不明」として扱い、利用実績による判定の対象から外します。取得できないことを理由に判定を止めないでください。

AIへ渡す前に整形する

1. ユーザーの名寄せ … システムごとにIDが違います（社員番号、メールアドレス、独自ID）。社員番号を軸にした対応表を作り、名寄せします。 ここで対応しないIDが残ったら、それ自体が棚卸の対象です（誰のものか分からないアカウント）
2. 権限名の正規化 … 権限カタログを引き、システムごとの権限名を共通の分類に対応づけます
3. 共有アカウント・システムアカウントの分離 … 人に紐づかないアカウント（バッチ実行用、監視用、テスト用）を分けます。これらは別の基準で棚卸します（用途の記録があるか、パスワードの管理者が誰か）
4. 異動日の考慮 … 異動直後は引き継ぎのため前部署の権限が残ることがあります。猶予期間（例：30日）を設け、それを超えたものだけを指摘します
5. 有効期限つき権限の抽出 … 申請台帳に有効期限が記録されている権限のうち、期限を過ぎているものを抽出します

AIに処理させる

突き合わせの判定は、プログラムで行います。 「退職者が権限を持っている」「申請記録がない」は、データの照合だけで判定できます。LLMを使う必要はありませんし、使うべきでもありません。

LLMにさせること：

4番目が実務では大きく効きます。 棚卸で一番進まないのは、業務部門の責任者に「この権限が必要かどうか」を答えてもらうことです。FIN_AP_APPROVER_L2 というコードを並べたメールを送っても、返事は来ません。「◯◯さんは、200万円未満の買掛金の支払を承認できる権限を持っています。現在の職務で必要でしょうか」と書かれていれば、答えられます。

AIに権限の削除を判断させないでください。 指摘と説明までです。「不要と思われる」という表現も避け、「申請記録が見つからない」「異動後30日を超えて前部署の権限が残っている」という事実だけを書かせます。 必要かどうかは、業務部門が決めることです。

指示内容を固定する

あなたは、社内システムのアクセス権限の棚卸を支援する担当者です。
突き合わせの結果に対して、業務部門の責任者が判断できる説明を作ってください。

【厳守事項】
- 権限の要否を判断しないでください。
  「不要と思われる」「削除すべき」と書かないでください。
  事実（申請記録がない、異動後◯日経過している、◯か月未使用）だけを書いてください。
- 権限の意味は、下記の権限カタログの記述だけに基づいて書いてください。
  カタログに記載がない権限は、意味を推測しないでください。
  description を null とし、「権限カタログに記載がありません」と書いてください。
- 職務分離の指摘は、下記のルールに明記された組み合わせに限ってください。
  ルールにない組み合わせを、あなたの判断で問題として挙げないでください。
  気づいた点がある場合は observations に分けて書いてください。
- 確認依頼文は、権限コードではなく、業務上の言葉で書いてください。
  「FIN_AP_APPROVER_L2 の要否をご確認ください」ではなく、
  「200万円未満の買掛金の支払を承認する権限」のように書いてください。
- 対象者の人事情報のうち、確認依頼文に書いてよいのは
  氏名・所属・職位だけです。評価、処遇、異動理由を書かないでください。

【権限カタログ】
{permission_catalog}

【職務分離ルール】
{sod_rules}

【突き合わせの結果】
対象者: {user_name}（社員番号 {employee_id} / 所属 {department} / 職位 {position}）
在籍区分: {employment_status} / 直近の異動日: {transfer_date}
保有している権限:
{permissions}
申請台帳の該当記録:
{approval_records}
最終利用日:
{last_used}
判定結果（プログラムによる）:
{findings}

「権限の要否を判断しないでください」の1行が、この構成の安全装置です。 これを書かないと、「この権限は職務上不要と考えられます」という文が生成されます。それを読んだ担当者が確認を省いて削除すると、業務が止まります。 権限の削除で業務が止まると、次の棚卸への協力が得られなくなります。

「ルールにない組み合わせを問題として挙げない」も必要です。 職務分離は、内部統制の設計として定められたものに従います。AIが独自に「これも危ない」と挙げ始めると、指摘が発散して読まれなくなります。気づいた点は observations に分けておき、内部統制部門がルールに加えるかを判断します。

出力形式を固定する

プログラムによる判定：

{
  "employee_id": "",
  "system": "",
  "permission_code": "",
  "permission_category": "",
  "finding_type": "terminated_user | post_transfer_residual | no_approval_record | approved_not_granted | unused | sod_conflict | unidentified_account",
  "detected_at": "",
  "evidence": {
    "employment_status": "",
    "department": "",
    "transfer_date": "",
    "days_since_transfer": 0,
    "approval_record_id": "",
    "last_used_date": "",
    "days_unused": 0
  },
  "risk_level": "critical | high | medium | low"
}

LLMによる説明：

{
  "employee_id": "",
  "permission_code": "",
  "description": "",
  "description_source": "catalog | not_in_catalog",
  "sod_conflicts": [
    { "rule_id": "", "combined_with": "", "explanation": "" }
  ],
  "observations": [],
  "confirmation_request_text": "",
  "needs_review": []
}

判定と説明を別のJSONで持ちます。 判定はデータの照合結果であり、確定した事実です。説明はLLMの生成物であり、誤りうるものです。この2つを混ぜると、監査で証跡として出すときに困ります。 「なぜこの権限が指摘されたのか」の根拠は、判定側のJSONだけで説明できる状態にしてください。

description_source を持つのは、権限カタログに記載があったのか、なかったのかを区別するためです。カタログにない権限が多いなら、カタログの整備が先です。

システムへ連携する

権限の削除・付与は、この構成から行いません。 すべて読み取りです。書き込み権限を持たせないことが、この構成の設計方針です。 権限を削除できる仕組みは、それ自体が攻撃対象になります。

人が確認する

すべての指摘を人が確認します。 ただし、優先順位を明確に分けます。

優先度1について、事前に方針を決めておいてください。 「退職者のアカウントは、確認を待たずに即時停止する」という方針が決まっていれば、この構成は当日中に検知して自動で停止申請を起票できます。方針がないと、検知しても止まります。

確認依頼の返事が来ないことが、この業務の最大の障害です。 対応状況を追跡し、期限を過ぎたものを再掲する仕組みを必ず入れてください。「返事がないので放置」が積み上がると、棚卸の意味がなくなります。

例外に対処する

記録を残す

• 各システムから取得した権限の一覧（取得日時つき。取得の生データを残す）
• 判定結果（evidence を含む）
• LLMが生成した説明と確認依頼文
• 権限所有者の回答（必要／不要／理由）
• 是正の実施記録（いつ、誰が、何を削除・追加したか）
• 取得に失敗したシステムと、その理由

監査で問われるのは「棚卸を行った証跡」です。 判定結果だけでなく、取得の生データと、取得に失敗した記録を残してください。「25本のうち24本しか確認できていない」ことが記録に残っている状態のほうが、「25本確認した」と書いてあって実態が違うより、はるかに安全です。

権限の一覧そのものが機密情報です。 「誰が何にアクセスできるか」は、攻撃者にとって価値の高い情報です。保管場所と閲覧権限を厳しく設定してください。