この記事では、コンテキスト認識アクセスの一般的なユースケースについて説明し、基本モードで開発された設定例を示します。
（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 |
| アクセスレベルの割り当て | 最上位の組織部門 すべてのアプリ |
特定の場所からのアクセスを許可または禁止する
支社のオフィスやパートナー企業のオフィスに定期的に出張する従業員がいる場合は、そうした従業員が社内リソースにアクセスできる地域を指定できます。
たとえば、セールスチームがオーストラリアやインドに定期的に出張している場合は、セールスチームの社内リソースへのアクセス元を本社オフィス、オーストラリア、インドに制限できます。出張期間中に個人の休暇で他の国に旅行する場合、旅行先の国から社内リソースにアクセスすることはできなくなります。
次の例では、セールスチームは米国（ホームオフィス）、オーストラリア、インドからのみ企業リソースにアクセスできます。
| アクセスレベルの名前 | sales_access |
| セールスチームがアクセスできる条件 | 属性に該当する |
| 条件 1 の属性 | アクセス元の地域 米国、オーストラリア、インド |
| アクセスレベルの割り当て | セールスチーム 営業担当者が使用するすべてのアプリ |
特定の国からのアクセスを拒否するポリシーを作成することもできます。その場合は、条件を満たしていないユーザーがアクセスできるように指定して、ブロックするアクセス元の国を入力します。
割り当てに複数のアクセスレベルを選択するのではなく、ネストしたアクセスレベルを使用する
特定の組織部門やグループ、アプリケーション（またはアプリケーション群）にアクセスレベルを割り当てようとすると、アプリケーションの数やアクセスレベルの数を減らすように求めるエラー メッセージが表示される場合があります。
このエラーを防ぐため、割り当てに使用する複数のアクセスレベルを 1 つのアクセスレベルにネストして、アクセスレベルの数を減らすことができます。アクセスレベルをネストするには、個別のアクセスレベルが含まれる複数の条件を OR 演算で結合します。
この例では、USWest、USEast、USCentral に 3 つの別々のアクセスレベルが関連付けられています。ここで、ユーザーが USWest または USEast または USCentral のアクセスレベルのいずれかを満たしている場合にアプリケーションにアクセスできるように、OR 演算子を使用して、ネストした 1 つのアクセスレベル（USRegions）を作成します。アクセスレベルを割り当てる際は、組織部門またはグループのアプリケーションにアクセスレベル USRegion を割り当てます。
|
アクセスレベルの名前 |
USRegions |
|
ユーザーのアクセス条件 |
属性に該当する |
|
条件 1 の属性 （各条件のアクセスレベルは 1 つのみ） |
アクセスレベル USWest |
|
条件 1 と条件 2 を演算子で結合 |
OR |
|
ユーザーのアクセス条件 |
属性に該当する |
|
条件 2 の属性 |
アクセスレベル USEast |
|
条件 2 と条件 3 を演算子で結合 |
OR |
|
ユーザーのアクセス条件 |
属性に該当する |
|
条件 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 つのアクセスレベル
たとえば、ユーザーのデバイスが暗号化されていて会社所有のものであっても、オペレーティング システムのバージョンが要件を満たしていない場合、そのユーザーはアクセスを拒否されます。
メリット: 設定が容易です。このアクセスレベルをアプリに割り当てる場合、ユーザーはすべての要件を満たしている必要があります。
デメリット: セキュリティ要件をさまざまな組織部門に個別に割り当てる場合は、セキュリティ要件ごとにアクセスレベルを作成する必要があります。
| アクセスレベルの名前 | device_security |
| ユーザーのアクセス条件 | 属性に該当する |
| 条件 1 の属性 （すべての属性を 1 つの条件に追加するか、 3 つの条件を作成し、それらを AND で結合できます） |
デバイス ポリシー デバイスの OS |
3 つの別個のアクセスレベル
たとえば、ユーザーの使用しているデバイスが、暗号化されており、指定バージョンより古いオペレーティング システムを搭載していて、個人所有のものである場合、そのユーザーは社内リソースにアクセスできます。
メリット: アクセスレベルを細かく定義でき、組織部門ごとにアクセスレベルを割り当てることが可能です。
デメリット: ユーザーは 1 つのアクセスレベルでのみ条件を満たしている必要があります。
| アクセスレベルの名前 | device_encryption |
| ユーザーのアクセス条件 | 属性に該当する |
| 条件 1 の属性 |
デバイス ポリシー |
| アクセスレベルの名前 | corp_device |
| ユーザーのアクセス条件 | 属性に該当する |
| 条件 1 の属性 |
デバイス ポリシー |
| アクセスレベルの名前 | min_os |
| ユーザーのアクセス条件 | 属性に該当する |
| 条件 1 の属性 |
デバイス ポリシー |
ネストされたアクセスレベルを含む 1 つのアクセスレベル
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 |
