SECURITY NOTE — 028

Google WorkspaceのContext-Aware Access (CAA) でパートナー企業連携のセキュリティを強化する実践ガイド

Google WorkspaceのContext-Aware Access (CAA)は、ユーザーのコンテキスト(場所、デバイスの状態など)に基づいてアクセスを制御する機能です。この機能は、外部パートナーとのセキュアなコラボレーション環境を構築する上で重要な役割を果たします。

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

  • 外部パートナーとのGoogle Workspace共有のセキュリティに課題を感じている情シス担当者
  • 情報漏洩リスクを最小限に抑えつつ、セキュアなコラボレーション環境を構築したいと考えている担当者
  • ゼロトラストの原則をGoogle Workspaceの外部アクセス管理に適用したいと考えている担当者

Context-Aware Access (CAA) とは?

Context-Aware Access (CAA) は、Google CloudおよびGoogle Workspaceにおいて、ユーザーがアクセスする際のコンテキスト(状況)に基づいてアクセスを許可または拒否するセキュリティ機能です。従来のセキュリティモデルが「どこから来たか」(IPアドレスなど)や「誰であるか」(認証情報)のみを重視していたのに対し、CAAは「どこから」「どのような状態のデバイスで」「どのユーザーが」といった、より多角的な情報を評価します。

この機能は、ゼロトラストセキュリティモデルの実現に不可欠な要素です。「決して信頼せず、常に検証する」というゼロトラストの原則に基づき、たとえ認証されたユーザーであっても、そのアクセスがポリシーで定義された安全なコンテキストを満たしているかを確認します。

Google Workspaceにおいては、Shared Drive、Gmail、Google ドキュメントなどのサービスへのアクセスを、管理者が設定したコンテキストに基づいて制御できます。これにより、内部ユーザーだけでなく、外部パートナーのアクセスに対しても、よりきめ細やかなセキュリティ対策を講じられます。

パートナー企業連携におけるセキュリティ課題

外部パートナーとの協業は、現代のビジネスにおいて不可欠です。Google Workspaceの共有機能は非常に便利ですが、その利便性の裏には情報漏洩のリスクが潜んでいます。

従来のアクセス管理では、主にIPアドレスによる制限が用いられてきました。しかし、リモートワークが普及し、パートナー企業も多様な環境からアクセスする現在、IPアドレスだけでは不十分です。例えば、パートナー企業の従業員が自宅のPCや管理されていない個人デバイスから機密情報にアクセスするリスクがあります。

また、一度アクセスを許可してしまうと、その後のアクセス状況をきめ細かく制御するのが難しいという課題もあります。過剰なアクセス権限を付与してしまうと、万が一アカウントが乗っ取られれば、広範囲な情報漏洩に直結します。このような状況では、企業は常に情報漏洩リスクと向き合うことになり、コンプライアンスの観点からも厳格な管理が必要です。

Google Workspace CAAで外部連携セキュリティを強化する仕組み

CAAは、以下のような複数のコンテキスト要素を組み合わせてアクセスを評価します。

  • ユーザーのID: 誰がアクセスしようとしているのか
  • ロケーション: アクセス元のIPアドレス、国、地域
  • デバイスの状態: デバイスが管理されているか、画面ロックが設定されているか、OSのバージョン、暗号化されているかなど
  • 時間: アクセスを試みている日時

これらのコンテキスト要素を組み合わせることで、「特定のパートナー企業のIPアドレス範囲内から、かつ管理されたデバイスを使用している場合のみ、特定の共有ドライブへのアクセスを許可する」といった、きめ細やかなポリシーを適用できます。

外部パートナーへの適用については、Google Cloudの公式ドキュメントでも「外部ID向けContext-Aware Access」として説明されています。外部パートナーがGoogle Workspaceの共有ドライブなどにアクセスする際も、同様にCAAポリシーを適用できます。具体的には、外部パートナーをメンバーとして含むGoogleグループを作成し、そのグループに対してアクセスレベルを設定することで、グループメンバーがリソースにアクセスする際のコンテキストを強制できます。

CAAポリシー設定の実践ガイド:パートナーアクセス制御の具体例

ここでは、特定のパートナー企業の従業員が、特定の共有ドライブにアクセスする際に、以下の条件を満たす必要があるというシナリオを想定します。

シナリオ: 「プロジェクトX」の共有ドライブへのアクセスは、以下の条件をすべて満たす場合にのみ許可する。

  1. アクセス元がパートナー企業の特定のIPアドレス範囲内であること
  2. アクセスに使用するデバイスが、パートナー企業によって管理されており、かつ画面ロックが設定されていること
  3. プロジェクトXのパートナー担当者用Googleグループのメンバーであること

前提条件

  • Google Workspace EnterpriseまたはEducation Plusエディション、あるいはCloud Identity Premium/Plusが必要です。
  • パートナー企業のデバイス管理状況を把握し、可能であればGoogleのデバイス管理に登録するか、パートナー企業側でデバイスの状態を証明できる仕組みが必要です。
  • パートナー企業のIPアドレス範囲を正確に把握している必要があります。

設定手順の概要

管理コンソール(admin.google.com)にログインし、「セキュリティ」カテゴリの下にある「Context-Aware Access」設定ページに進みます。UIの正確なナビゲーション表記はバージョンにより変わる場合があるため、作業時はGoogle Workspace管理者ヘルプの「Context-Aware Accessの設定」ページ(support.google.com/a/answer/9062453)も並行して参照することを推奨します。設定の大まかな流れは以下のとおりです。

  1. デバイス管理設定の確認: パートナー企業のデバイスがGoogle Workspaceで管理されているか、または管理対象外デバイスのアクセスを許可しつつ、特定の状態をチェックできる設定が必要です。
  2. IPアドレス範囲の定義: パートナー企業のアクセス元IPアドレス範囲を管理コンソールに登録します。
  3. アクセスレベルの作成: 管理コンソールの「アクセスレベルを追加」から、IPアドレス・デバイスの状態・グループメンバーシップを組み合わせた条件を定義します。条件が複数ある場合、管理コンソール上ではAND結合として扱われます。
  4. Googleグループの作成: プロジェクトXのパートナー担当者専用のGoogleグループを作成し、外部パートナーをメンバーとして追加します。
  5. アクセスレベルの適用: 作成したアクセスレベルを、共有ドライブまたは共有ドライブを共有しているGoogleグループに適用します。

アクセスレベルの論理構造例

Google Workspace管理コンソールでアクセスレベルを作成する際、内部的には以下のような論理構造を持つポリシーが生成されます。ここでは、管理コンソールで設定する項目が、どのようにポリシーの条件となるかを示します。

{
  "title": "PartnerAccessLevel_ProjectX",
  "description": "プロジェクトX共有ドライブ向けパートナーアクセスレベル",
  "conditions": [
    {
      "conditionType": "IP_SUBNETWORK",
      "value": ["203.0.113.0/24", "198.51.100.0/24"]
    },
    {
      "conditionType": "DEVICE_POLICY",
      "value": {
        "requireScreenlock": true,
        "allowedDeviceManagementLevels": ["COMPANY_MANAGED"]
      }
    },
    {
      "conditionType": "USER_GROUP_MEMBERSHIP",
      "value": "partner-project-x@yourdomain.com"
    }
  ],
  "combiningFunction": "AND"
}

上記のJSONは、Google Workspace管理コンソールで設定するアクセスレベルの論理的な概念を示すものであり、実際のAPIで利用する厳密な形式とは異なる場合があります。管理コンソールではGUIを通じてこれらの条件を組み合わせます。

設定のポイント

  • IPアドレスの正確性: パートナー企業のIPアドレス範囲は変更される可能性があるため、定期的な確認が必要です。
  • デバイス管理: パートナー企業が管理するデバイスの状態をGoogle Workspaceが把握できるように、可能な限りGoogleのデバイス管理への登録を促すか、信頼できる証明書ベースの認証を検討します。
  • グループの活用: 外部パートナーを直接OUに入れることはできないため、Googleグループを活用してアクセスレベルを適用するのが一般的です。

CAA導入のメリット・デメリット

メリット

  • きめ細やかなアクセス制御: IPアドレスだけでなく、デバイスの状態やロケーションなど多様なコンテキストを組み合わせて、より厳格なアクセス制御を実現できます。
  • 情報漏洩リスクの低減: 未管理デバイスや信頼できないネットワークからのアクセスをブロックすることで、機密情報への不正アクセスリスクを大幅に減らせます。
  • ゼロトラストセキュリティモデルへの移行: 「常に検証する」というゼロトラストの原則をGoogle Workspace環境に適用し、セキュリティ体制を強化できます。
  • コンプライアンス強化: 外部パートナーとの情報共有におけるセキュリティポリシーを具体的に実装し、監査要件への対応を強化します。

デメリット

  • 初期設定の複雑さ: 複数の条件を組み合わせるため、ポリシーの設計と設定にはある程度の専門知識と時間が必要です。
  • 運用負荷: パートナー企業のIPアドレス変更やデバイスポリシーの見直しなど、運用開始後も定期的なメンテナンスが必要です。
  • ユーザー体験への影響: ポリシーの誤設定は、正当なユーザーのアクセスを妨げ、ユーザーからの問い合わせ増加につながります。導入前には十分なテストと、パートナー企業への事前周知が重要です。
  • エディション要件: Google Workspace Enterprise/Education Plus、またはCloud Identity Premium/Plusが必要なため、追加コストが発生します。

まとめ:次のステップへ

Google WorkspaceのContext-Aware Access (CAA)は、外部パートナーとのセキュアなコラボレーションを実現するための強力なツールです。従来のアクセス管理では難しかった、きめ細やかな条件に基づくアクセス制御を可能にし、情報漏洩リスクを大幅に低減します。

設定と運用に一定のコストはかかりますが、その分だけ情報セキュリティの強化とゼロトラスト原則の実現に対して確実な効果が得られます。まずは、最もリスクが高いと判断されるパートナー連携からCAAの導入を検討し、段階的に適用範囲を広げていくのが現実的なアプローチです。

御社のセキュリティ要件に合わせたCAAポリシーの設計や導入、運用に関するご相談があれば、ぜひ専門家にご相談ください。


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

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

CONTACT

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

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

一社ずつ、一から。