AUTOMATION NOTE — 098

GWS MDM×CAA:オフラインアクセス制御の設計判断

Google Workspaceでは、MDM (Mobile Device Management) および Context-Aware Access (CAA) を活用して、デバイスのオフラインアクセスを組織単位 (OU) やグループ単位で柔軟に制御できます。これは、企業のセキュリティポリシーを強化し、情報漏洩リスクを低減するために不可欠な対策です。

この記事を読んだほうが良い人

  • Google Workspaceを管理しており、部門やグループごとにオフラインアクセスのリスク管理を強化したい情シス担当者
  • OU (組織部門) 単位でのオフラインアクセス制御は設定済みだが、部門横断的なグループへの適用方法に悩んでいる方
  • MDMとCAAのどちらを使うべきか、あるいは組み合わせて使うべきか、設計の判断軸を知りたい方
  • オフラインアクセス制御のコンプライアンス監査を自動化する方法に関心がある方

Google Workspace MDM オフラインアクセス 制御の課題とMDM・CAAの役割

Google Workspaceにおけるオフラインアクセスは、ユーザーの利便性を高める一方で、デバイスの紛失・盗難時に情報漏洩のリスクを伴います。特に、機密情報を扱う部門や特定のプロジェクトグループに対しては、より厳格な制御が求められます。

OU単位での制御は基本的な対策として有効ですが、部門横断的なプロジェクトチームや、特定のセキュリティ要件を持つグループに対しては、OUだけでは柔軟な対応が難しい場合があります。ここで、MDMとCAAのそれぞれの特性を理解し、適切に組み合わせることが重要になります。

MDM (Mobile Device Management) の特性

Google WorkspaceのMDMは、デバイスそのもののポリシー管理を行います。管理コンソールのデバイス管理設定から、モバイルデバイスやエンドポイントのオフライン同期設定を制御できます。

  • 強み: デバイス全体に適用されるため、ユーザーが利用する全てのGoogle Workspaceサービスに一貫したポリシーを適用しやすいです。オフライン同期を許可する・しないといった基本的な設定が可能です。
  • 弱み: OU単位での適用が基本となり、特定のグループにのみ異なるポリシーを適用するには、OU構造を複雑化させるか、他の手段との併用が必要になります。

CAA (Context-Aware Access) の特性

CAAは、ユーザーがアクセスする際に、デバイスの状態、IPアドレス、地理的位置などの「コンテキスト」に基づいてアクセスを許可するかどうかを判断します。これにより、より詳細なアクセス制御が実現します。

  • 強み: アクセスレベルを定義することで、特定のグループに対して、特定の条件(例: 会社の管理下にあるデバイスからのみ、特定のIPアドレス範囲からのみ)が満たされた場合にのみオフラインアクセスを許可するといった、柔軟な制御が可能です。グループ単位での適用も容易です。
  • 弱み: MDMのようにデバイスそのものの設定を直接変更するものではなく、アクセスを許可するか否かの判断レイヤーで機能します。オフラインアクセス自体を有効にするかどうかの設定はMDMやGoogleドライブの設定に依存します。

MDMとCAAの組み合わせによる設計判断フロー

オフラインアクセスの制御を強化するためには、MDMとCAAのどちらか一方だけでなく、それぞれの強みを活かした組み合わせが効果的です。以下に、MDM単体、CAA単体、組み合わせの使い分けと、設計判断の考え方を示します。

MDM・CAA・組み合わせの使い分け

制御方法 目的 強み 弱み
MDM単体 デバイス全体の一貫したオフラインポリシー適用 デバイスそのものの同期設定を制御、OU単位でシンプルに適用 グループ単位での柔軟な制御が難しい、OU構造の複雑化を招く可能性
CAA単体 特定のコンテキスト下でのオフラインアクセス許可 デバイスの状態やIPアドレスに基づく詳細なアクセス制御、グループ単位での適用が容易 オフラインアクセス自体の有効/無効は直接制御しない、ポリシー設定が複雑化しやすい
MDM + CAA デバイスとアクセスコンテキスト両面からの厳格な制御 OUとグループのハイブリッド制御、多層防御によるセキュリティ強化、柔軟性とセキュリティの両立 設定が複雑になる傾向、設計に綿密な計画が必要

設計の考え方:どちらをどのフェーズで使うか

基本的な考え方としては、まずMDMで全社的なオフラインアクセスのベースラインを設定し、その上でCAAを用いて特定のグループや高リスクユーザーに対して例外的な、より厳格なアクセスレベルを適用するのが効果的です。

  1. MDMによるベースライン設定:

    • 全社的にオフラインアクセスを許可するかどうかをMDMで決定します。
    • 特定のOU(例: 役員、開発部門)ではMDMでオフラインアクセスを「許可しない」設定を適用し、情報漏洩リスクを低減します。
    • 一般的な従業員向けOUでは「許可する」設定とし、利便性を確保します。
  2. CAAによるグループ単位の例外・強化設定:

    • MDMでオフラインアクセスを「許可する」設定のOUに属するユーザーの中で、特定のグループ(例: 機密プロジェクトグループ)に対して、さらに厳しいアクセス条件を課したい場合にCAAを使用します。
    • 例えば、「機密プロジェクトグループ」のメンバーがオフラインアクセスを利用できるのは、会社の管理対象デバイスからのみ、といったアクセスレベルをCAAで定義し、対象グループに適用します。
    • 管理コンソールのコンテキストアウェアアクセス設定で、デバイスの状態(管理対象か、最新のOSかなど)や地域情報などを条件とするアクセスレベルを作成し、対象のGoogleグループに紐付けます。

このハイブリッドアプローチにより、OUによる部門ごとの大枠の制御と、Googleグループによる部門横断的なプロジェクト単位でのきめ細やかな制御を両立できます。

GAS 監査自動化:オフラインアクセス制御のコンプライアンス維持

MDMとCAAを組み合わせてオフラインアクセス制御を設計しても、その設定が正しく適用されているか、あるいは意図せず変更されていないかを継続的に監査することが重要です。この監査作業を効率化するために、Admin SDK Reports APIとGAS (Google Apps Script) を活用できます。

Admin SDK Reports APIの活用

Admin SDK Reports APIは、Google Workspaceの監査ログや利用状況レポートにプログラムでアクセスするためのAPIです。これを利用することで、ユーザーのデバイス同期状況や、Admin Consoleでの設定変更履歴などを取得できます。

特に、activities.list メソッドを使って、管理コンソールでの設定変更イベント(例: MDMポリシーの変更、CAAアクセスレベルの変更)や、Googleドライブのオフライン同期に関するイベントを監視できます。

GAS (Google Apps Script) による自動監査の概要

GASを使えば、Admin SDK Reports APIを呼び出し、定期的に監査レポートを生成するスクリプトを記述できます。これにより、手動での確認作業を削減し、コンプライアンス違反の早期発見に繋げられます。

以下は、Admin SDK Reports APIを使って監査ログを取得するGASの概念的なコード例です。

/**
 * Admin SDK Reports API を使用して、Google Workspace の監査ログを取得する関数の例
 * この関数は概念的なものであり、実際の運用には認証設定やエラーハンドリングが必要です。
 */
function getAdminAuditLogs() {
  // Admin SDK Reports API を有効にする必要があります (Google Cloud Project および Apps Script プロジェクトで)
  // 必要なスコープ: 'https://www.googleapis.com/auth/admin.reports.audit.readonly'

  const today = new Date();
  const oneWeekAgo = new Date(today.getTime() - (7 * 24 * 60 * 60 * 1000)); // 1週間前

  const optionalArgs = {
    domain: 'your_domain.com', // 自身のGoogle Workspaceドメインを指定
    startTime: oneWeekAgo.toISOString(),
    endTime: today.toISOString(),
    maxResults: 1000
  };

  try {
    // 管理コンソールのアクティビティログを取得 (例: デバイス管理関連の変更)
    // applicationName に 'admin' を指定すると、管理コンソールでの操作ログが取得されます
    const adminActivities = AdminReports.Activities.list('all', 'admin', optionalArgs);

    if (adminActivities.items && adminActivities.items.length > 0) {
      console.log('--- Admin Activities (Last 7 Days) ---');
      adminActivities.items.forEach(activity => {
        // デバイスポリシーやCAA設定に関連するイベントをフィルタリングして表示
        if (activity.events) {
          activity.events.forEach(event => {
            // 例: デバイスポリシーの変更イベントを検出
            if (event.name === 'CHANGE_DEVICE_POLICY' || event.name === 'CREATE_ACCESS_LEVEL') {
              console.log(`User: ${activity.actor.email}, Event: ${event.name}, Date: ${new Date(activity.id.time)}`);
              console.log(`Details: ${JSON.stringify(event.parameters)}`);
            }
          });
        }
      });
    } else {
      console.log('No admin activities found.');
    }

    // Googleドライブのオフライン同期に関連するイベントを取得する場合
    // applicationName に 'drive' を指定
    // const driveActivities = AdminReports.Activities.list('all', 'drive', optionalArgs);
    // ... 同様に処理 ...

  } catch (e) {
    console.error('Error fetching admin audit logs: ' + e.toString());
  }
}

このスクリプトは、AdminReports.Activities.list メソッドを使って、指定期間内の管理コンソール操作ログを取得する例です。applicationNameadmin に設定することで、デバイスポリシーの変更やCAAアクセスレベルの作成・変更といったイベントを検出できます。検出したイベントは、スプレッドシートに記録したり、特定の情シス担当者にメールで通知したりするよう拡張することで、自動監査システムとして機能させることが可能です。

まとめ:組織に合わせたオフラインアクセス制御の継続的な最適化

Google Workspaceにおけるオフラインアクセス制御は、単一の機能で完結するものではなく、MDMとCAA、そしてAdmin SDK Reports APIを組み合わせることで、より堅牢かつ柔軟なセキュリティポリシーを構築できます。

OU単位での制御をベースラインとし、特定のグループに対してCAAで詳細なアクセスレベルを適用するハイブリッドな設計は、利便性とセキュリティのバランスを取る上で非常に有効です。さらに、GASとAdmin SDK Reports APIによる自動監査を導入することで、設定のコンプライアンスを継続的に維持し、変更があった際には速やかに検知・対応できる体制を整えることが可能です。

組織の規模やセキュリティ要件は常に変化するため、一度設計したら終わりではなく、定期的にポリシーを見直し、継続的に最適化していくことが、情報資産を守るための重要な鍵となります。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。

CONTACT

御社の IT 部門、ここにあります。

「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。

一社ずつ、一から。