Akamai向けWallarmコネクタ¶

Akamai CDNのプロパティを通じてAPIを配信しているお客様向けに、Wallarmは専用のEdgeWorkerコードバンドルを提供します。このEdgeWorkerをデプロイすると、リクエストはオリジンに到達する前に検査と保護のためWallarmノードへルーティングされます。この方法により、オリジンのインフラを変更することなく、エッジでAPIトラフィックを直接保護できます。

AkamaiのコネクタとしてWallarmを使用するには、Wallarmノードを外部にデプロイし、AkamaiでWallarm提供のコードバンドルを適用して、トラフィックをWallarmノードへ解析のためにルーティングする必要があります。

Akamai向けWallarmコネクタは、同期（インライン）と非同期（アウトオブバンド）の両方のトラフィック解析をサポートします:

ユースケース¶

このソリューションは、Akamai CDN経由で配信されるAPIの保護に適しています。

制限事項¶

Akamai向けWallarmコネクタにはいくつかの制限があります:

• When deploying the Wallarm service with the LoadBalancer type using the Helm chart, a trusted SSL/TLS certificate is required for the domain. Self-signed certificates are not yet supported.

• Custom blocking page and blocking code configurations are not yet supported.

  All blocked malicious traffic is returned with status code 403 and the default block page.

• Rate limiting by Wallarm rules is not supported.

  Rate limiting cannot be enforced on the Wallarm side for this connector. If you need rate limiting, use the features built into your API gateway or cloud platform.

• Multitenancy is not supported.

  All protected APIs are managed under a single Wallarm account; separating protection across multiple accounts for different infrastructures or environments is not yet supported.

加えて、以下のEdgeWorkersプラットフォームの制約がコネクタ設計に影響します:

• httpRequestドメイン制限 – EdgeWorkerからのサブリクエストは、すでにAkamaiが配信しているドメイン（すなわち、設定済みのプロパティ）を宛先にする必要があります

• HTTPSのみのサブリクエスト – 別のプロトコルが指定されている場合、EdgeWorkersは自動的にHTTPSへ変換します

• イベントモデルの制限 – リクエストおよびレスポンスのボディはresponseProviderイベント内でのみアクセス可能です

これらの制約により、Wallarm EdgeWorkerは同じプロパティへサブリクエストを発行するresponseProvider関数として実装されています。このサブリクエストにはカスタムヘッダーx-wlrm-checkedが含まれ、無限ループを防止し、トラフィックをWallarmノードへルーティングできるようにします。

要件¶

Akamai上にWallarm EdgeWorkerをデプロイするには、以下の要件を満たしてください:

• Akamaiの各種テクノロジーの理解

• 契約でAkamai EdgeWorkersが有効化されていること

• オリジンバックエンドの用意

  • 到達可能なオリジンサーバー上でAPIサービスが稼働していること
  • オリジンドメインがCNAMEレコードでAkamaiのプロパティホスト名に解決すること

• 保護対象のオリジンへトラフィックを転送するよう構成されたAkamaiプロパティ

  • プロパティにはDefault RuleにOrigin Server behaviorを含める必要があります
  • プロパティに配信対象ホスト用の有効なTLS証明書が必要です

• DNSゾーン（例: customer.com）を管理でき、Wallarmノード用プロパティに割り当てる専用サブドメイン（例: node.customer.com）を用意できること

  プロパティの作成後、AkamaiはEdge Hostname（例: node.customer.com.edgesuite.net）を返します。DNSに、選択したサブドメインをこのEdge Hostnameへ向けるCNAMEレコードを作成する必要があります。

デプロイ¶

1. Wallarmノードをデプロイ¶

WallarmノードはWallarmプラットフォームの中核コンポーネントであり、デプロイが必要です。受信トラフィックを検査し、悪意のある活動を検出し、脅威を緩和するように設定できます。

Akamaiコネクタの場合、ノードはお客様のインフラ内にのみデプロイできます。

セルフホスト型ノードのデプロイに使用するアーティファクトを選択し、各手順に従ってください:

• LinuxのベアメタルまたはVMインフラ向けのAll-in-oneインストーラー

• コンテナ化デプロイを使用する環境向けのDockerイメージ

• Kubernetesを利用するインフラ向けのHelmチャート

2. Wallarmコードバンドルを取得しEdgeWorkersを作成¶

Akamai EdgeWorkersでWallarmコードバンドルを取得して実行するには、次の手順に従ってください:

1. support@wallarm.comに連絡し、Wallarmコードバンドルを入手します。

2. Akamai Control Center → EdgeWorkers → Create EdgeWorker IDに進み、コードバンドルwallarm-mainをインポートします。

   これは、リクエストをWallarmノード経由でルーティングするメインのEdgeWorkerです。

3. 別のEdgeWorker IDを作成し、wallarm-spバンドルをインポートします。

   これはなりすまし防止のために推奨されるEdgeWorkerです。プロパティは不要です。

3. Wallarmノード用プロパティを作成¶

1. Akamai Property Managerで新しいプロパティを作成します:

   • Property name / hostname: 専用のノードホスト名（例: node.customer.com）。このホスト名はお客様が管理するDNSゾーンに属している必要があります。
   • Property type: Dynamic Site Accelerator
   • Origin type: Web server
   • Origin Hostname: デプロイ済みのWallarmノードの実際のアドレス

2. プロパティのTLSを構成します:

   • Akamai Managed Certificateを選択する（Akamaiがnode.customer.comの証明書を発行・管理します）、または
   • 必要に応じて独自の証明書をアップロードします。

3. プロパティを保存します。AkamaiがEdge Hostnameを生成します。例:

   node.customer.com.edgesuite.net
   

4. DNSゾーンで、ノードホスト名をEdge Hostnameに向けるCNAMEレコードを作成します。例:

   node.customer.com → node.customer.com.edgesuite.net
   

5. stagingでプロパティを有効化して動作を確認し、続けてproductionで有効化します。

4. オリジンプロパティで変数を設定¶

既存のオリジンプロパティを開き、→ Edit New Versionで次の変数を設定します:

Set Variable behaviorを使用すると、コネクタモードやボディ検査の設定をルート単位やファイルタイプ単位で詳細に調整できます。

5. Wallarm EdgeWorkerルールを追加¶

オリジンプロパティで空の新規ルールを作成します:

• Criteria:

  If 
  Request Header 
  x-wlrm-checked
  does not exist
  

• Behavior: EdgeWorkers → the wallarm-main EdgeWorker

より複雑な構成では、この条件にパスのチェックを組み合わせ（例: /api/*のパスにのみ適用）、APIトラフィックだけをWallarmで処理するようにできます。

6. なりすまし防止ルールを追加¶

オリジンプロパティでもう1つ空の新規ルールを作成します:

• Criteria:

  If 
  Request Header 
  x-wlrm-checked
  exists
  

• Behavior: EdgeWorkers → the wallarm-sp EdgeWorker

このルールは、ヘッダーx-wlrm-checkedがPMUSER_WALLARM_HEADER_SECRETの値と一致することを保証します。一致しない値はブロックされ、クライアントがWallarmのチェックを回避することを防ぎます。

より複雑な構成では、この条件にパスのチェックを組み合わせ（例: /api/*のパスにのみ適用）、APIトラフィックだけをWallarmで処理するようにできます。

7. プロパティを保存して有効化¶

1. 新しいオリジンプロパティのバージョンを保存します。

2. staging環境で有効化します。

3. 検証後、productionで有効化します。

テスト¶

デプロイしたEdgeWorkersの動作をテストするには、次の手順に従ってください:

1. Akamai CDNにテスト用のPath Traversal攻撃を送信します:

   curl http://<AKAMAI_CDN>/etc/passwd
   

2. Wallarm Console → Attacksセクション（US CloudまたはEU Cloud）を開き、攻撃が一覧に表示されていることを確認します。

   

   Wallarmノードのモードがブロッキングに設定されている場合は、リクエストもブロックされます。

Wallarm EdgeWorkersのアップグレード¶

デプロイ済みのWallarm EdgeWorkersを新しいバージョンへアップグレードするには:

1. wallarm-main用に作成したEdgeWorkerへ移動します。

2. Create Versionを押し、新しいwallarm-mainコードバンドルをアップロードします。

3. staging環境で有効化します。

4. 検証後、productionで有効化します。

5. wallarm-spコードバンドルのバージョンが変わった場合は、同じ手順を繰り返します。

EdgeWorkerのアップグレードでは、特にメジャーバージョン更新時に、Wallarmノードのアップグレードが必要となる場合があります。セルフホスト型ノードのリリースノートはNative Nodeの変更履歴を参照してください。非推奨の回避と将来のアップグレード簡素化のため、ノードの定期的な更新を推奨します。

Was this page helpful?

How can we improve this article? (Optional)

Information is unclear or confusing

Insufficient information

Outdated or incorrect information

0/240

Send