この記事では、コンテキストアウェア アクセスの一般的なユースケースについて説明し、Basic モードで開発された設定例を示します。
（CEL エディターを使用して）詳細モードで開発されたアクセスレベルの例については、詳細モードでのコンテキストアウェア アクセスの例をご覧ください。
契約業者のアクセスを社内ネットワーク経由でのみ許可する
多くの企業では、契約業者による社内リソースへのアクセスを制限したいと考えています。たとえば、一般的なサポート電話への対応や、ヘルプセンターやコールセンターでの業務を請負業者に委託している企業などです。正社員と同様に、コンテキストアウェア アクセス ポリシーの対象となるには、契約社員もサポートされているライセンスが必要です。
この例では、契約業者は特定の企業 IP アドレス範囲からのみ企業リソースにアクセスできます。
| アクセスレベルの名前 | contractor_access |
| 契約業者のアクセス条件 | 属性に該当する |
| 条件 1 の属性 | IP サブネット（パブリック） 74.125.192.0/18 |
| アクセスレベルの割り当て | 契約業者の組織部門 契約業者が使用するすべてのアプリ |
既知のハイジャッカー IP アドレスからのアクセスをブロックする
企業のリソースが侵害されないように、多くの企業が既知の高リスク ソースへのアクセスをブロックしています。
この例では、IP アドレス 74.125.195.105 がブロックされています。セッションが他の IP アドレスから開始された場合、ユーザーは企業リソースにアクセスできます。複数の IP アドレスと範囲を指定できます。
| アクセスレベルの名前 | block_highrisk |
| ユーザーのアクセス条件 | 属性に該当しない |
| 条件 1 の属性 | IP サブネット（パブリック） 74.125.195.105 |
| アクセスレベルの割り当て | 最上位の組織部門 すべてのアプリ |
Google Cloud の特定のプライベート ネットワークからのアクセスを許可する
多くの企業は、Virtual Private Cloud（VPC）を介してユーザー トラフィックを Google にルーティングしています。VPC は、Google Cloud 環境内の安全で隔離されたネットワークです。
VPC を介してルーティングされるトラフィックは、プライベート IP アドレスを使用する可能性があることに注意してください。これにより、パブリック IP またはリージョン ポリシーで問題が発生する可能性があります。
この例では、これらの特定の VPC からのトラフィックを許可できます。
| アクセスレベルの名前 | vpc_access |
| ユーザーのアクセス条件 | 属性に該当する |
| 条件 1 の属性 |
IP サブネット（プライベート） プライベート IP サブネットワーク: //compute.googleapis.com/projects/project- name-test/global/networks/network-name VPC サブネット: 74.125.192.0/18 |
| アクセスレベルの割り当て |
すべてのユーザーの組織部門 すべてのアプリの請負業者が使用する |
次の点にご留意ください。
- ノーリファラーのみ: このアクセスレベルは、許可リストに登録済みの VPC から Google のサーバーに直接到達するトラフィックに対してのみ機能します。トラフィックが別のネットワークまたはトンネルを通過してから到達した場合、アクセスは許可されません。Google は、トラフィックをサーバーに送信する最後の VPC のみを認識します。
- 管理者権限: VPC を表示してこのアクセスレベルを設定するには、管理者に適切な Identity and Access Management（IAM）ロール（compute.networks.list、compute.subnetworks.list など）が必要です。
- 外部 VPC: 許可リストに登録する VPC は、現在の Google Cloud ドメインの外部のものでかまいません。外部 VPC を追加するには、管理者に表示権限が必要です。
特定の場所からのアクセスを許可または禁止する
従業員が定期的に遠隔地の企業オフィスやパートナー オフィスに出張する場合は、企業リソースにアクセスできる地理的位置を指定できます。
たとえば、営業担当者のグループがオーストラリアとインドの顧客を定期的に訪問している場合は、そのグループのアクセスを本社とオーストラリア、インドに制限できます。出張の一環として個人的な休暇で他の国に旅行する場合、その国から会社の社内リソースにアクセスすることはできません。
この例では、営業グループは米国（本社）、オーストラリア、インドからのみ企業リソースにアクセスできます。
| アクセスレベルの名前 | sales_access |
| セールスチームがアクセスできる条件 | 属性に該当する |
| 条件 1 の属性 | アクセス元の地域 米国、オーストラリア、インド |
| アクセスレベルの割り当て | 営業担当者のグループ すべてのアプリの営業担当者が使用する |
条件を満たしていない場合にユーザーがアクセスできるように指定することで、特定の国からのアクセスを拒否するポリシーを作成することもできます。アクセスをブロックする国をリストします。
割り当て時に複数のアクセスレベルを選択する代わりに、ネストされたアクセスレベルを使用する
特定の組織部門またはグループとアプリケーション（またはアプリケーションのセット）にアクセスレベルを割り当てようとすると、アプリケーションまたはアクセスレベルの数を減らすよう求めるエラー メッセージが表示されることがあります。
このエラーを回避するには、割り当て時に使用されるアクセスレベルの数を減らします。具体的には、複数のアクセスレベルを 1 つのアクセスレベルにネストします。ネストされたアクセスレベルは、複数の条件を OR 演算で結合します。各条件には個別のアクセスレベルが含まれます。
この例では、USWest、USEast、USCentral は 3 つの別々のアクセスレベルにあります。たとえば、USWest、USEast、USCentral のいずれかのアクセスレベルを満たしているユーザーがアプリケーションにアクセスできるようにするとします。この場合、OR 演算子を使用して、単一のネストされたアクセスレベル（USRegions）を作成できます。アクセスレベルを割り当てる際には、組織部門またはグループのアプリケーションにアクセスレベル USRegions を割り当てます。
|
アクセスレベルの名前 |
USRegions |
|
ユーザーのアクセス条件 |
属性に該当する |
|
条件 1 の属性 （各条件のアクセスレベルは 1 つのみ） |
アクセスレベル 米国西部 |
|
条件 1 と条件 2 の組み合わせ方法 |
OR |
|
ユーザーのアクセス条件 |
属性に該当する |
|
条件 2 の属性 |
アクセスレベル 米国東部 |
|
条件 2 と条件 3 を |
または |
|
ユーザーのアクセス条件 |
属性に該当する |
|
条件 3 の属性 |
アクセスレベル USCentral |
パソコンについては会社が所有していることを必須とするが、モバイル デバイスについては必須としない
パソコンについては会社が所有していることを必須とするが、モバイル デバイスについては会社が所有していることを必須としない会社があるとします。
まず、パソコンのアクセスレベルを作成します。
|
アクセスレベルの名前 |
aldesktop_access |
|
ユーザーがアクセスできる条件 |
属性に該当する |
|
条件 1 の属性 |
デバイス ポリシー
デバイスの暗号化 = サポート対象外 デバイスの OS macOS = 0.0.0 Windows =0.0.0 Linux OS = 0.0.0 Chrome OS = 0.0.0 |
次に、モバイル デバイスのアクセスレベルを作成します。
|
アクセスレベルの名前 |
almobile_access |
|
ユーザーがアクセスできる条件 |
属性に該当する |
|
条件 1 の属性 |
デバイスの OS iOS = 0.0.0 Android = 0.0.0 |
基本的なデバイス セキュリティを要件にする
現在、ほとんどの大企業では、従業員が暗号化され、オペレーティング システムの最小バージョンを満たすデバイスから企業リソースにアクセスすることを義務付けています。中には、会社所有のデバイスを使用することを求める企業もあります。
そのようなポリシーは、すべての組織部門に対して設定したり、センシティブ データを扱う組織部門（経営幹部、財務、人事など）に限定して設定したりすることができます。
デバイスの暗号化、オペレーティング システムの最小バージョン、会社所有のデバイスを含むポリシーを構成する方法はいくつかあります。それぞれにメリットとデメリットがあります。
すべてのセキュリティ要件を含む 1 つのアクセスレベル
次の例では、暗号化されたデバイス、オペレーティング システムの最小バージョン、会社所有のデバイスの各属性が 1 つのアクセスレベルに含まれています。ユーザーは社内リソースにアクセスするために、すべての条件を満たしている必要があります。
たとえば、ユーザーのデバイスが暗号化されていて、会社所有であるにもかかわらず、準拠バージョンのオペレーティング システムを実行していない場合、アクセスは拒否されます。
メリット: 設定が簡単です。このアクセスレベルをアプリに割り当てる場合、ユーザーはすべての要件を満たしている必要があります。
デメリット: セキュリティ要件を異なる組織部門に個別に割り当てるには、セキュリティ要件ごとに個別のアクセスレベルを作成する必要があります。
| アクセスレベルの名前 | device_security |
| ユーザーのアクセス条件 | 属性に該当する |
| 条件 1 の属性 （すべての属性を 1 つの条件に追加するか、 3 つの条件を作成して「かつ」で結合できます）。 |
デバイス ポリシー デバイスの OS |
3 つの別個のアクセスレベル
次の例では、暗号化されたデバイス、オペレーティング システムの最小バージョン、会社所有のデバイスの各属性が 3 つの別個のアクセスレベルに含まれています。ユーザーは社内リソースにアクセスするために、1 つのアクセスレベルでのみ条件を満たしている必要があります。アクセスレベルの論理 OR です。
たとえば、暗号化されたデバイスを使用し、個人用デバイスで古いバージョンのオペレーティング システムを実行しているユーザーはアクセスできます。
利点: アクセスレベルをきめ細かく定義できます。組織部門ごとにアクセスレベルを割り当てることが可能です。
デメリット: ユーザーは 1 つのアクセスレベルの条件を満たせばよい。
| アクセスレベルの名前 | device_encryption |
| ユーザーのアクセス条件 | 属性に該当する |
| 条件 1 の属性 |
デバイス ポリシー |
| アクセスレベルの名前 | corp_device |
| ユーザーのアクセス条件 | 属性に該当する |
| 条件 1 の属性 |
デバイス ポリシー |
| アクセスレベルの名前 | min_os |
| ユーザーのアクセス条件 | 属性に該当する |
| 条件 1 の属性 |
デバイス ポリシー |
ネストされたアクセスレベルを含む 1 つのアクセスレベル
次の例では、暗号化されたデバイス、オペレーティング システムの最小バージョン、会社所有のデバイスの各セキュリティ要件が 3 つの別個のアクセスレベルに含まれていて、これら 3 つのアクセスレベルが 4 つ目のアクセスレベルにネストされています。
4 番目のアクセスレベルをアプリに割り当てると、ユーザーはアクセス権を取得するために、3 つのネストされたアクセスレベルの条件をそれぞれ満たす必要があります。アクセスレベルの論理 AND です。
たとえば、デバイスが暗号化されていて、個人用デバイスで古いバージョンのオペレーティング システムを実行しているユーザーはアクセスを拒否されます。
利点: アクセスレベル 1、2、3 でセキュリティ要件を分離する柔軟性を維持できます。アクセスレベル 4 を使用することで、すべてのセキュリティ要件を満たすポリシーを適用することもできます。
デメリット: アクセスレベル 1、2、3 はアプリに直接割り当てられないため、監査ログにはアクセスレベル 4 へのアクセス拒否のみが記録されます。
上記の「3 つの個別のアクセスレベル」で説明したように、「device_encryption」、「corp_device」、「min_os」の 3 つのアクセスレベルを作成します。次に、3 つの条件を持つ「device_security」という 4 つ目のアクセスレベルを作成します。各条件はその属性としてアクセスレベルを持ちます（各条件に追加できるアクセスレベル属性は 1 つだけです）。
| アクセスレベルの名前 | device_security |
| ユーザーのアクセス条件 | 属性に該当する |
| 条件 1 の属性 （各条件のアクセスレベルは 1 つのみ） |
アクセスレベル device_encryption |
| 条件 1 と条件 2 の組み合わせ方法 | AND |
| ユーザーのアクセス条件 | 属性に該当する |
| 条件 1 の属性 | アクセスレベル corp_device |
| 条件 2 と条件 3 を | AND |
| ユーザーのアクセス条件 | 属性に該当する |
| 条件 1 の属性 | アクセスレベル min_os |