25/12/26 12:55

【Okta】OIGを利用した生成AIの一時利用申請・承認【生成AIセキュリティ対策シリーズ】

はじめに

こんにちは、ネクストモード株式会社のSaaSおじさん久住です。

ネクストモードではID統合管理（IDaaS）のOktaを利用して各SaaSへのシングル・サインオンやプロビジョニングの一元管理をしています。

本記事では、Okta Identity Governance (OIG) の「アクセスリクエスト機能」を活用し、ユーザーからのGemini利用申請を承認フローに乗せ、一時的な利用を許可する仕組みを構築する方法をご紹介します。

OIGの様々な機能については下記ブログで紹介しておりますので、是非御覧ください！

生成AI時代の新たなガバナンス課題

昨今急速に普及する生成AIは、業務効率化の大きな可能性を秘めています。その一方で、Gemini (Google Workspace) やChatGPTなどの導入においては、情報漏洩、コンプライアンス違反、シャドーITといったセキュリティリスクが常に伴います。

多くの企業が「全面禁止」か「全面許可」など利用に関連する会社方針で悩んでいるかと思いますが、ビジネスの成長を止めないためには、リスクを管理しながら安全に活用する「ゼロトラストに基づいたガバナンス」が不可欠です。

今回実現する構成とゴール

今回のゴールは、「デフォルトではGemini利用を禁止し、申請・承認を得たユーザーのみ、指定された期間だけ特定の機能（今回はアプリ利用とDrive連携）を使えるようにする」ことです。

実現するフロー

ユーザー: Oktaダッシュボードから「Gemini一時利用」を申請します。
承認者: 申請内容（利用目的など）を確認し、承認します。
Okta (OIG): 承認後、ユーザーを「Gemini利用許可グループ」に30日間だけ自動で追加します。
Okta (Provisioning): Oktaグループへの追加をトリガーに、Google Workspace側の特定グループにユーザーが追加されます (Group Push)。
Google Workspace: このグループに対し、Geminiの「アプリ利用」と「Drive利用」が有効化されています。
(30日後): ユーザーは「Gemini利用許可グループ」から自動で削除され、Geminiが利用できなくなります。

この仕組みにより、IT部門が手動で権限を付与・剥奪する手間をなくし、権限の削除漏れ（＝シャドーアクセス）を防ぎます。

前提条件

Okta Identity Governance (OIG) のライセンスが有効であること。
OktaとGoogle WorkspaceがSAMLで連携され、プロビジョニング（Lifecycle Management）が設定済みであること。
Google Workspace側でGeminiが契約されており、組織単位 (OU) やグループ単位で機能のオン/オフが制御可能であること。

やってみた

Step 1: Google Workspace側のアクセス制御設定

まずはじめに組織全体のGeminiの利用については、全てオフにしておきます。

Google Workspace管理者画面 → 生成AI → Geminiアプリ

okta-gemini-001

Google Workspace管理者画面 → 生成AI → Gemini for Workspace

okta-gemini-002

次にGeminiの機能を制御する受け皿となるグループ（例: gemini-partial-users@example.com）を作成します。

okta-gemini-003

このグループに対して、Geminiのサービス設定画面で以下のように制御をかけます。

Gemini (gemini.google.com) の利用: ON

okta-gemini-005

Google Drive内のGemini機能 (要約など): ON
Gmail内のGemini機能: OFF
その他 (Meet, Chatなど): OFF

Step 2: Okta側のグループとGroup Push設定

次に、Okta側でOIGのアクセスリクエストの対象となるグループ（例: OIG_Allow_Gemini_Temporary）を作成します。

okta-gemini-006

そして、OktaのGroup Push機能を使い、Oktaの OIG_Allow_Gemini_Temporary グループのメンバーが、Google Workspaceの gemini-partial-users グループと同期するように設定します。

すでにGoogleグループは作成しているので「グループをリンク」で設定します。

okta-gemini-007

Group Pushについての詳細を知りたい方は下記ブログをご参照ください。

Step 3: OIG アクセスリクエストの設定 (申請フロー構築)

ここがOIGの核となる部分です。

Okta管理画面の [Identity Governance] > [Access Requests] に移動し、Create request typeをクリックします。
「Gemini一時利用申請」というリクエストタイプを作成します
質問フォーム: 申請時に「利用目的」などをユーザーに入力させるフォームを定義します。
承認フロー: 「ユーザーのマネージャー」または「特定のIT管理者」が承認するステップを定義します。
リソースの定義: ユーザーが申請する対象として、Step 2で作成したOktaグループ OIG_Allow_Gemini_Temporary を指定します。
アクセス期間: 最も重要な設定です。承認されたアクセスが有効な期間（例: 30日間）を指定します。

詳細な設定内容は省略しますが、下記のようなフローを作成しました。

okta-gemini-010

実際の動作確認 (ユーザー体験)

実際の動作について、今回は自分自身で体験してみます。
初期段階ではGoogle Workspace上でどのグループにも所属していません。

okta-gemini-011

Geminiを利用できる権限も付与されていないため、Geminiアプリの画面にいっても、使えないことが確認できます。

okta-gemini-015

① 申請 (ユーザー)

Oktaダッシュボードの「アクセスを要求する」から「Gemini一時利用申請」を選択し、理由を書いて送信します。

② 承認 (承認者)

マネージャーはOktaのダッシュボードやメール/Slack/Teams等で通知を受け取り、申請内容を確認して「Approve」します。
今回はSlack上で承認してみます。

okta-gemini-014

Approveを押すとOktaグループ「OIG_Allow_Gemini_Temporary」に追加されたことが確認できました。

③ 利用開始 (ユーザー)

承認後、ユーザーはOktaグループに追加され、通常数分以内にGoogle Workspace側のグループへ同期され、Google Workspaceにログインし直すと、許可されたGeminiの機能（アプリとDrive）が使えるようになっています。

④ 自動剥奪 (システム)

30日後、ユーザーは自動的にグループから除外され、Geminiの機能にアクセスできなくなります。

OIGで生成AIアクセスを管理するメリット

今回のような構成をOIGで組むことには、明確なメリットがあります。

ガバナンスの強化（最小権限の原則）
- 「必要な人」が「必要な理由」で「必要な期間」だけアクセスすることを強制できます。
ライフサイクル管理の完全自動化
- IT部門が手動で行っていた権限付与・剥奪作業がゼロになります。特に「権限の削除漏れ」を完全に防ぐことができます。
監査対応（トレーサビリティ）
- 「誰が」「いつ」「なぜ」Geminiの利用を申請し、「誰が」承認したかのログ（証跡）がOIGに一元的に記録され、監査レポートも容易に作成できます。
セルフサービスによるUX向上
- ユーザーはIT部門にチケットを発行する代わりに、Oktaからセルフサービスで申請でき、承認されればすぐに利用を開始できるため、利便性が向上します。

さいごに

生成AIは「禁止」するのではなく、「管理」して活用する時代です。

Okta Identity Governance (OIG) は、Geminiのような強力な生成AIツールに対して、セキュリティと利便性を両立させるための「ガバナンスの効いた入り口」を提供します。

特に、権限の棚卸しや期限切れアクセス権の管理は、従来のIT運用において非常に工数がかかる部分でした。
OIGのアクセスリクエストと自動化されたライフサイクル管理は、生成AI時代のセキュリティ対策において非常に強力なソリューションとなります。

Okta, 技術, 生成AIセキュリティ対策シリーズ