社内システムの認可、 Google・Microsoftで どう組むか。

ログインできても、何をしてよいかは別に決める。

OWASP Top 10は2021年版に続き2025年版でも、アクセス制御（認可）の不備が1位。

OWASP Top 10:2025 A01。OWASPの試験データでは、すべてのアプリに何らかの不備

認可は、入口・判定・運用の3層で組む。

IdP（GoogleやMicrosoftのID基盤）の機能は入口と運用に多い。判定と足りない運用はアプリ側で用意する。

3層の分け方はこの資料の整理（NIST・OWASPを元にした）

役割で粗く分け、属性と関係で絞る。

条件を役割だけで表すと、役割が数千に増えることもある（ロール爆発）。

NIST SP 800-162・Kuhnら（2010）・Google Zanzibar（2019）

判定は1か所に集め、どの適用点からも同じ判定を呼ぶ。

適用点：判定を呼び、その結果で通すか止めるかを決める所

判定を1か所に集めると、ルールをまとめてテストできる。

複数のアプリなら共通の判定サービス（OPA・Cerbos・OpenFGAなど）に。APIの標準はAuthZEN 1.0

既定で拒否し、操作とデータ取得のたびに確かめる。

拒否はログに残し、他部署・自己承認・期限切れの権限が拒否されるかを試す。

OWASPの認可の指針とTop 10:2025 A01の対策から

割り当てた人だけを、条件を確かめて通す。

入口が決めるのは、入れるかと追加の認証まで。何をしてよいかはアプリが判定する。

条件付きアクセスにEntra ID P1、端末の条件にChrome Enterprise Premiumなどが必要

Googleはアプリが所属を問い合わせ、Microsoftは役割をトークンで渡す。

groupsクレームは200件（SAMLは150件）を超えると省かれるので、役割はアプリロールで渡す。

hdクレームで組織を判定。入れ子の所属の確認にはEnterpriseかCloud Identity Premiumが要る

IdPのグループで粗く分け、細かい範囲はアプリで判定する。

利用者の部署はIdPから受け取り、申請の部署・金額・関係はアプリのデータで判定する。

例は架空。Microsoftもアプリロールは変わりにくい区分に限るよう案内している

人事の属性から、グループとアカウントを自動で作り、外す。

動的グループ：属性の条件でメンバーが自動で決まるグループ（Entra ID P1など）

1. 1

   人事が登録する

   部署・役職をIdPの属性に入れる

2. 2

   グループが決まる

   属性の条件で、動的グループに入る

3. 3

   アカウントが作られる

   SCIMなどの自動プロビジョニングでSaaSにも

4. 4

   異動・退職で外れる

   異動はグループから外れ、退職は停止

IdPでアカウントを止めても、アプリが発行したセッションは残る。失効させる経路を作る。

Googleの停止は自社アプリへ通知されない。Directory APIの変更通知か定期的な照会で検知

管理者の権限は、必要なときだけ期限付きで与える。

4つの手順はPIM（Entra ID P2かID Governance）とGoogle CloudのPAM

1. 1

   理由を書いて申請する

   作業と必要な時間を書く

2. 2

   承認者が承認する

   上長やセキュリティ担当が確かめる

3. 3

   MFAで有効化する

   承認とは別に、本人の追加認証を求める

4. 4

   期限で自動的に外れる

   PAMの期限は30分〜7日で決める

期限なしで持たせてよいのは、普段のSSOを通らない緊急用アカウントだけ。2つ以上用意し、使われたら通知する。

Workspaceの管理者ロールは、管理者が期限を決めて付与する（2026年9月から）

例外の権限には期限を付け、定期的に棚卸しする。

例外の権限：人事の属性では決まらない権限（案件への参加・代理の担当など）

Googleで棚卸しをするなら、一覧・確認・取り消しの手順を自社で用意する。

棚卸し：権限を持つ人を定期的に確かめ直し、要らない権限を外すこと

AIエージェントの権限は、依頼した人の権限の中で必要な分に限る。

両社とも、エージェント用のIDと入口の条件を提供し始めた。

例：Entra Agent ID・Google Agent Identity。IAP for Agentsはプレビュー

入口から棚卸しまで、両社の機能を並べる。

Googleでは、所属の問い合わせはアプリで、棚卸しの手順は自社で用意する。

必要なライセンスは機能ごとに違い、変わることがある（2026年10月1日時点）

最初は、入口・権限表・判定・期限と棚卸しの順に固める。

1. 1

   入口をIdPに寄せる

   割り当てた人だけ通し、退職時はセッションも切る

2. 2

   権限表を作る

   グループ・役割・範囲・条件を表に

3. 3

   判定を1か所に集める

   全適用点で呼び、拒否を試す

4. 4

   期限と棚卸しを入れる

   管理者は期限付き、棚卸しは定期に

Googleなら、2で所属の問い合わせを、4で棚卸しの手順を自社で用意する。

順序はこの資料の提案。Google Cloudでの実装例は記事「社内アプリの認可設計」

ライセンスと提供状況は2026年10月1日時点。導入前に各社の公式ページで確認