Google Cloud Armor: IP アドレスと地理的フィルタリング

Media CDN は Google Cloud Armor を使用して、IP アドレス許可リストと拒否リストのサポートと、国コードと地域コード(地理的なロケーション)に基づくフィルタリング制御を提供します。次のことが可能です。

  • IPv4 アドレスと IPv6 アドレスおよび範囲(CIDR)に基づいてリクエストを拒否します。
  • 国コード(地域)に基づいてリクエストを許可または拒否します。
  • IPv4 アドレスと IPv6 アドレスおよび範囲(CIDR)に基づくリクエストを許可します。

これらの機能によって、コンテンツ ライセンス制限が設定された特定のロケーションにあるユーザーにコンテンツのダウンロードを制限できます。また、会社の IP アドレスにのみテストまたはステージング エンドポイントへのアクセスを許可したり、既知の不正なクライアント IP アドレスのリストを拒否したりできます。

Google Cloud Armor ポリシーは、キャッシュに保存されたコンテンツとキャッシュミスの両方を含め、Media CDN から配信されるすべてのコンテンツに適用されます。

IP アドレスと地理ポリシーは Edge キャッシュ サービス(EdgeCacheService)ごとに構成されます。このサービスの IP アドレス(またはホスト名)宛てのすべてのリクエストには、一貫したセキュリティ ポリシーが適用されます。サービスごとに異なるセキュリティ ポリシーを適用でき、必要に応じて、異なる地域に複数のサービスを作成できます。

ユーザーレベルでコンテンツをきめ細かく保護するには、Google Cloud Armor ポリシーとともに署名付き URL と署名付き Cookie を使用することをおすすめします。

セキュリティ ポリシーの構成

セキュリティ ポリシーを構成する手順は次のとおりです。

始める前に

Google Cloud Armor セキュリティ ポリシーを Edge キャッシュ サービスに接続するには、次の条件を満たす必要があります。

  • Google Cloud Armor について理解している。
  • ポリシーを適用する既存の Edge キャッシュ サービスがある。
  • 推奨されるオプション: Edge キャッシュ サービスでロギングを有効にして、ブロックされたリクエストを識別できるようにしている。

また、セキュリティ ポリシーを承認して作成し、Edge キャッシュ サービスに接続するには、次の Identity and Access Management 権限も必要です。

  • compute.securityPolicies.addAssociation
  • compute.securityPolicies.create
  • compute.securityPolicies.delete
  • compute.securityPolicies.get
  • compute.securityPolicies.list
  • compute.securityPolicies.update
  • compute.securityPolicies.use

既存の証明書を Edge キャッシュ サービスにアタッチする必要があるユーザーは、次の IAM 権限のみが必要です。

  • compute.securityPolicies.get
  • compute.securityPolicies.list
  • compute.securityPolicies.use

roles/networkservices.edgeCacheUser ロールには、これらの権限がすべて含まれます。

セキュリティ ポリシーの作成

Google Cloud Armor セキュリティ ポリシーは複数のルールで構成され、各ルールではリクエストの一致条件(式)のセットを定義します。たとえば、式にはインド国内にあるクライアントのマッチング ロジックを含めることができ、関連するアクションは許可されます。リクエストがルールと一致しない場合、すべてのルールが試行されるまで評価は次のルールに進みます。

セキュリティ ポリシーには、許可アクションを指定したデフォルト ルールがあります。デフォルト ルールでは、前のルールと一致しないリクエストが許可されます。これを deny ルールに変更することで、前のルールに一致したリクエストだけを allow し、それ以外のリクエストをすべて拒否できます。

次の例で、HTTP 403 でオーストラリアに配置されたすべてのクライアントをブロックし、他のすべてのリクエストを許可するルールを作成する方法を示します。

gcloud

CLOUD_ARMOR_EDGE タイプの新しいポリシーを作成するには、次のコマンドを実行します。

gcloud compute security-policies create block-australia \
    --type="CLOUD_ARMOR_EDGE" --project="PROJECT_ID"

これにより、最も低い優先度(priority: 2147483647)のデフォルトの許可ルールを持つポリシーが作成されます。

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/securityPolicies/block-australia].

次に、優先度の高いルールを追加できます。

gcloud compute security-policies rules create 1000 \
    --security-policy=block-australia --description "block AU" \
    --expression="origin.region_code == 'AU'" --action="deny-403"

次のような出力が表示されます。

Updated [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/securityPolicies/block-australia].

Terraform

resource "google_compute_security_policy" "default" {
  name        = "block-australia"
  type        = "CLOUD_ARMOR_EDGE"
  description = "block AU"

  rule {
    action      = "deny(403)"
    description = "block AU"
    priority    = "1000"
    match {
      expr {
        expression = "origin.region_code == 'AU'"
      }
    }
  }
  rule {
    action   = "allow"
    priority = "2147483647"
    match {
      versioned_expr = "SRC_IPS_V1"
      config {
        src_ip_ranges = ["*"]
      }
    }
    description = "default rule"
  }
}

ポリシーを調べると、次の 2 つのルールが表示されます。最初のルールはオーストラリアからのリクエスト(origin.region_code == 'AU')をブロックし、優先度が最も低い 2 番目のルールは、優先度が最も高いルールと一致しないすべてのトラフィックを許可します。

kind: compute#securityPolicy
name: block-australia
rules:
- action: deny(403)
  description: block AU
  kind: compute#securityPolicyRule
  match:
    expr:
      expression: origin.region_code == 'AU'
  preview: false
  priority: 1000
- action: allow
  description: default rule
  kind: compute#securityPolicyRule
  match:
    config:
      srcIpRanges:
      - '*'
    versionedExpr: SRC_IPS_V1
  preview: false
  priority: 2147483647
  ruleNumber: '1'
type: CLOUD_ARMOR_EDGE

このポリシーを Media CDN に接続するには、次のセクションをご覧ください。

サービスへのポリシーの添付

us-only-delivery-policy という名前の既存の Google Cloud Armor ポリシーを prod-media-service という名前の Edge キャッシュ サービスに接続するには:

gcloud

gcloud edge-cache services update prod-media-service \
    --edge-security-policy=us-only-delivery-policy

ポリシー アタッチメントを表示する

既存のサービスに関連付けられているポリシーを確認するには、そのサービスを調べます(記述します)。

gcloud

gcloud edge-cache services describe MY_SERVICE

サービスの edgeSecurityPolicy フィールドには、接続されているポリシーが記述されています。

name: "MY_SERVICE"
edgeSecurityPolicy: "SECURITY_POLICY

ポリシーを削除する

既存のポリシーを削除するには、関連するサービスを更新し、ポリシーとして空の文字列を渡します。

gcloud

gcloud edge-cache services update MY_SERVICE \
  --edge-security-policy=""

gcloud edge-cache services describe MY_SERVICE コマンドの出力から edgeSecurityPolicy フィールドが省略されました。

ブロックされたリクエストを特定

ブロックされたリクエストをログに記録するには、その Edge キャッシュ サービスに対してロギングが有効になっている必要があります。

フィルタリング ポリシーによって許可または拒否されたリクエストは、Logging に記録されます。拒否されたリクエストをフィルタリングするには、次の prod-video-service 構成の Logging クエリを使用します。

resource.type="edge_cache_service"
jsonPayload.statusDetails="denied_by_security_policy"

レスポンス コードのカスタマイズ

Google Cloud Armor ルールは、特定のルールに関連付けられたアクションとして特定のステータス コードを返すように構成できます。ほとんどの場合、HTTP 403(deny-403)コードを返して、クライアントがルールによってブロックされたことを明記することをおすすめします。

サポートされているステータス コードは次のとおりです。

  • HTTP 403 (禁止)
  • HTTP 404(未検出)
  • HTTP/1.1 502(不正なゲートウェイ)

次の例は、返されるステータス コードの構成方法を示しています。

gcloud

ルールに関連付けられたアクションとして [allow | deny-403 | deny-404 | deny-502] のいずれかを指定するには、次のコマンドを実行します。この例では、HTTP 502 を返すようにルールを構成しています。

gcloud compute security-policies rules create 1000 \
    --security-policy=block-australia --description "block AU" \
    --expression="origin.region_code == 'AU'" --action="deny-502"

セキュリティ ポリシーのルールごとに、異なるステータス コード レスポンスを定義できます。

以下のような詳細なユースケースの例を考えてみましょう。

例: 許可された IP アドレスを除き、国外のクライアントを拒否する

メディア配信でよく発生するのは、コンテンツのライセンスや支払いメカニズムがあるリージョン外のクライアントからの接続を拒否している場合です。

たとえば、インドにあるクライアントと、192.0.2.0/24 の範囲内の許可リストに登録された IP アドレス(コンテンツ パートナーとお客様の従業員)のみを許可し、それ以外はすべて拒否する場合があります。

これを行うには、Google Cloud Armor カスタムルール言語を使用します。

origin.region_code == "IN" || inIpRange(origin.ip, '192.0.2.0/24')

この式は allow ルールとして構成され、デフォルトの deny ルールが他のすべてのクライアントと一致するように構成されています。セキュリティ ポリシーには、常にデフォルト ルールがあります。通常、明示的に許可しない default deny トラフィックに構成します。また、一部のトラフィックをブロックし、他のトラフィックをすべて default allow でブロックすることもできます。

セキュリティ ポリシーの出力で、次の点に注意してください。

  • 優先度が最も高い(priority: 0)ルールは、インドからのトラフィック、または IP アドレスの定義リストからのトラフィックを許可します。
  • 最も低い優先度ルールは default deny を表します。ルールエンジンは、優先度の高いルールが true と評価されないすべてのクライアントを拒否します。
  • ブール演算子を使用すると、複数のルールを連結できます。

次のポリシーは、インドのクライアントからのトラフィックを許可し、定義した IP 範囲のクライアントを許可し、他のすべてのトラフィックを拒否します。

gcloud

次の security-policies describe コマンドを実行します。

gcloud compute security-policies describe allow-india-only

次のような Google Cloud Armor ポリシーが出力されます。

kind: compute#securityPolicy
name: allow-india-only
type: "CLOUD_ARMOR_EDGE"
rules:
- action: allow
  description: ''
  kind: compute#securityPolicyRule
  match:
    expr:
      expression: origin.region_code == "IN" || inIpRange(origin.ip, '192.0.2.0/24')
  preview: false
  priority: 0
- action: deny(403)
  description: Default rule, higher priority overrides it
  kind: compute#securityPolicyRule
  match:
    config:
      srcIpRanges:
      - '*'
    versionedExpr: SRC_IPS_V1
  preview: false
  priority: 2147483647

カスタム レスポンス ヘッダー{region_code} ヘッダー変数で設定することもできます。このヘッダーは、JavaScript で検査してクライアントに反映できます。

例: IP アドレスと IP 範囲によって悪意のあるクライアントをブロックする

これを行うには、Google Cloud Armor カスタムルール言語を使用します。

inIpRange(origin.ip, '192.0.2.2/32') || inIpRange(origin.ip, '192.0.2.170/32')

IPv4 では /8 マスクまで、IPv6 では /32 までの IP 範囲をブロックできます。ストリーミング プラットフォームの一般的なケースでは、コンテンツのライセンス回避を最小限に抑えるために、プロキシまたは VPN プロバイダの下り(外向き)IP 範囲をブロックします。

inIpRange(origin.ip, '192.0.2.0/24') || inIpRange(origin.ip, '198.51.100.0/24') || inIpRange(origin.ip, '203.0.113.0/24') || inIpRange(origin.ip, '2001:DB8::B33F:2002/64')

IPv4 アドレス範囲と IPv6 アドレス範囲の両方がサポートされています。

例: 特定の地域の固定リストのみを許可する

国コードのリストがある場合は、ブール OR 演算子 || を使用して一致条件を連結できます。

次の式では、Google Cloud Armor カスタムルール言語を使用して、オーストラリアまたはニュージーランドから識別されたユーザーが識別されます。

origin.region_code == "AU" || origin.region_code == "NZ"

さらに、origin.ip または inIpRange(origin.ip, '...') の式で連結し、指定地域からでなくても、テスター、パートナー、会社の IP 範囲を許可できます。

カスタム式を持つ各ルールのサブ式の数は文書化されています。さらに多くのサブ式を連結する必要がある場合は、1 つのポリシー内で複数のルールを定義します。

例: 特定の国からクライアントをブロックする

あまり一般的でない例としては、特定の国からクライアントをブロックし、それ以外の国からのリクエストを許可する場合があります。

これを行うには、国、およびリージョンを特定できないクライアントの両方をブロックするポリシーを作成し、他のすべてのリクエストのデフォルト許可ルールを使用します。

次の例は、カナダのクライアントとロケーション不明のクライアントをブロックし、他のすべてのトラフィックを許可するポリシーを示しています。

  kind: compute#securityPolicy
  name: block-canada
  type: "CLOUD_ARMOR_EDGE"
  rules:
  - action: deny(403)
    description: ''
    kind: compute#securityPolicyRule
    match:
      expr:
        expression: origin.region_code == "CA" || origin.region_code == "ZZ"
    preview: false
    priority: 0
  - action: allow
    description: Default rule, higher priority overrides it
    kind: compute#securityPolicyRule
    match:
      config:
        srcIpRanges:
        - '*'
      versionedExpr: SRC_IPS_V1
    preview: false
    priority: 2147483647

Logging の適用アクション

リクエストログには、適用されたセキュリティ ポリシー、およびリクエストが許可(ALLOW)されたか拒否(DENY)されたかに関する詳細情報が記録されます。

ロギングを有効にするには、サービスで logConfig.enabletrue に設定されていることを確認します。ログが有効になっていないサービスは、セキュリティ ポリシー イベントをログに記録しません。

クライアントが米国外にあり、米国外からのリクエストを拒否する deny-non-us-clients というセキュリティ ポリシーが適用されている場合の、拒否されたリクエストのログエントリを以下に示します。

enforcedSecurityPolicy:
  name: deny-non-us-clients
  outcome: DENY

Google Cloud Armor ポリシーが関連付けられないサービスには、enforcedSecurityPolicy.name の値として no_policy が含まれ、ALLOWoutcome が含まれます。たとえば、ポリシーが接続されていないサービスのリクエストログ エントリは次の値を持ちます。

enforcedSecurityPolicy:
  name: no_policy
  outcome: ALLOW

GeoIP 分類について

Media CDN は、Google の内部 IP 分類データソースを利用して、ある IP アドレスから場所(地域、都道府県、都市)を取得します。複数のプロバイダから移行するか、複数のプロバイダ間でトラフィックを分割する場合、少数の IP アドレスが異なるロケーションに関連付けられることがあります。

  • Google Cloud Armor は、ISO 3166-1 alpha 2 リージョン コードを使用して、クライアントを地理的なロケーションに関連付けます。
  • たとえば、米国の場合は US、オーストラリアの場合は AU のようになります。
  • 1 つのリージョンは 1 つの国に対応する場合がありますが、必ずしもそうならない場合もあります。たとえば、US コードには米国のすべての州、1 つの特別区、6 つの海外領土が含まれます。
  • 詳細については、Unicode 技術標準の unicode_region_subtag をご覧ください。

  • ロケーションを導出できないクライアントの場合、origin.region_codeZZ に設定されます。

Media CDN エンドポイント(routing.routeRules[].headerActions[].responseHeadersToAdd[] を使用)に地域ヘッダーをレスポンス ヘッダーに追加したり、に提供した地域データを反映したりできます。最初の統合とテストで geoIP データソースの違いを検証するための Cloud Function の関数をご覧ください。

また、Media CDN リクエストログには、既存のデータソースに対して検証できる clientRegion やその他のクライアント固有のデータが含まれています。

次のステップ