基本モードでのコンテキストアウェア アクセスの例

この記事では、コンテキスト認識アクセスの一般的なユースケースについて説明し、基本モードで開発された設定例を示します。

(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.listcompute.subnetworks.list など)が必要です。
  • 外部 VPC: 許可リストに登録する VPC は、現在の Google Cloud ドメインの外部のものでかまいません。外部 VPC を追加するには、管理者に表示権限が必要です。

特定の場所からのアクセスを許可または禁止する

支社のオフィスやパートナー企業のオフィスに定期的に出張する従業員がいる場合は、そうした従業員が社内リソースにアクセスできる地域を指定できます。

たとえば、セールスチームがオーストラリアやインドに定期的に出張している場合は、セールスチームの社内リソースへのアクセス元を本社オフィス、オーストラリア、インドに制限できます。出張期間中に個人の休暇で他の国に旅行する場合、旅行先の国から社内リソースにアクセスすることはできなくなります。

次の例では、セールスチームは米国(ホームオフィス)、オーストラリア、インドからのみ企業リソースにアクセスできます。

アクセスレベルの名前 sales_access
セールスチームがアクセスできる条件 属性に該当する
条件 1 の属性 アクセス元の地域
米国、オーストラリア、インド
アクセスレベルの割り当て セールスチーム
営業担当者が使用するすべてのアプリ

特定の国からのアクセスを拒否するポリシーを作成することもできます。その場合は、条件を満たしていないユーザーがアクセスできるように指定して、ブロックするアクセス元の国を入力します。

割り当てに複数のアクセスレベルを選択するのではなく、ネストしたアクセスレベルを使用する

特定の組織部門やグループ、アプリケーション(またはアプリケーション群)にアクセスレベルを割り当てようとすると、アプリケーションの数やアクセスレベルの数を減らすように求めるエラー メッセージが表示される場合があります。

このエラーを防ぐため、割り当てに使用する複数のアクセスレベルを 1 つのアクセスレベルにネストして、アクセスレベルの数を減らすことができます。アクセスレベルをネストするには、個別のアクセスレベルが含まれる複数の条件を OR 演算で結合します。

この例では、USWest、USEast、USCentral に 3 つの別々のアクセスレベルが関連付けられています。ここで、ユーザーが USWest または USEast または USCentral のアクセスレベルのいずれかを満たしている場合にアプリケーションにアクセスできるように、OR 演算子を使用して、ネストした 1 つのアクセスレベル(USRegions)を作成します。アクセスレベルを割り当てる際は、組織部門またはグループのアプリケーションにアクセスレベル USRegion を割り当てます。

アクセスレベルの名前

USRegions

ユーザーのアクセス条件

属性に該当する

条件 1 の属性

(各条件のアクセスレベルは 1 つのみ)

アクセスレベル

USWest

条件 1 と条件 2 の組み合わせ方法

または

ユーザーのアクセス条件

属性に該当する

条件 2 の属性

アクセスレベル

USEast

条件 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 つの条件を作成し、それらを AND で結合できます)

デバイス ポリシー
デバイスの暗号化 = 暗号化あり
会社所有のデバイス = 必須

デバイスの OS
macOS
Windows
Chrome の各バージョン

3 つの別個のアクセスレベル

次の例では、暗号化されたデバイス、オペレーティング システムの最小バージョン、会社所有のデバイスの各属性が 3 つの別個のアクセスレベルに含まれています。ユーザーは社内リソースにアクセスするために、1 つのアクセスレベルでのみ条件を満たしている必要があります。つまり、アクセスレベルの論理和(OR)です。

たとえば、ユーザーの使用しているデバイスが、暗号化されており、指定バージョンより古いオペレーティング システムを搭載していて、個人所有のものである場合、そのユーザーは社内リソースにアクセスできます。

メリット: アクセスレベルを細かく定義できます。組織部門ごとにアクセスレベルを割り当てることが可能です。
デメリット: ユーザーは 1 つのアクセスレベルでのみ条件を満たしている必要があります。

アクセスレベルの名前 device_encryption
ユーザーのアクセス条件 属性に該当する
条件 1 の属性

デバイス ポリシー
デバイスの暗号化 = 暗号化済み

アクセスレベルの名前 corp_device
ユーザーのアクセス条件 属性に該当する
条件 1 の属性

デバイス ポリシー
会社所有デバイス = 必須

アクセスレベルの名前 min_os
ユーザーのアクセス条件 属性に該当する
条件 1 の属性

デバイス ポリシー
オペレーティング システムの最小バージョン =
Windows、Mac、Chrome の各バージョン

ネストされたアクセスレベルを含む 1 つのアクセスレベル

次の例では、暗号化されたデバイス、オペレーティング システムの最小バージョン、会社所有のデバイスの各セキュリティ要件が 3 つの別個のアクセスレベルに含まれています。これら 3 つのアクセスレベルが 4 つ目のアクセスレベルにネストされています。

4 つ目のアクセスレベルをアプリに割り当てる場合、ユーザーはアプリにアクセスするために、ネストされた 3 つのアクセスレベルのそれぞれにおいて条件を満たしている必要があります。つまり、アクセスレベルの論理積(AND)です。

たとえば、ユーザーの使用しているデバイスが、暗号化されており、指定バージョンより古いオペレーティング システムを搭載していて、個人所有のものである場合、そのユーザーはアクセスを拒否されます。

メリット: セキュリティ要件をアクセスレベル 1、2、3 として柔軟に分けることができます。アクセスレベル 4 を使用することで、すべてのセキュリティ要件を満たすポリシーを適用することもできます。
デメリット: 監査ログにはアクセスレベル 4 に対して拒否されたアクセスだけが記録されます(アクセスレベル 1、2、3 に対してではなく)。これは、アクセスレベル 1、2、3 がアプリに直接割り当てられていないからです。

上述の「3 つの別個のアクセスレベル」で説明したように、3 つのアクセスレベル(device_encryption、corp_device、min_os)を作成します。次に、3 つの条件を含む 4 つ目のアクセスレベル(device_security)を作成します。各条件はその属性としてアクセスレベルを持ちます(各条件に追加できるアクセスレベル属性は 1 つだけです)。

アクセスレベルの名前 device_security
ユーザーのアクセス条件 属性に該当する
条件 1 の属性
(各条件のアクセスレベルは 1 つのみ)
アクセスレベル
device_encryption
条件 1 と条件 2 の組み合わせ方法 AND
ユーザーのアクセス条件 属性に該当する
条件 1 の属性 アクセスレベル
corp_device
条件 2 と条件 3 を演算子で結合 AND
ユーザーのアクセス条件 属性に該当する
条件 1 の属性 アクセスレベル
min_os