0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@tyskJ

OCI WAF エッジポリシーで Web アプリケーションを保護する

0
Posted at

001samune.png

はじめに

本記事では、以下についてまとめます。

  • OCI WAF エッジポリシー について
  • 使用方法 (デモ)

OCI WAF について

OCI WAF は、L7レベルのトラフィックを監視し、外部からの不正リクエストからWebアプリケーションを保護するマネージドサービスです。
クロスサイト・スクリプティング(XSS)、SQLインジェクション、およびその他のOWASP定義の脆弱性を含むインターネットの脅威に対してルールを作成および管理することが可能です。

OCI WAFには、機能提供時(2019年)からある エッジポリシー(Global WAF) と、2021年から新たに提供されている WAF ポリシー(Regional WAF) の２種類が存在します。

詳細は割愛しますが、各ユースケースは以下のとおりです。

  • Global WAF: 全てのパブリックWEBアプリケーション（OCI, オンプレミス、他クラウド）
  • Regional WAF: OCI VCN 内のパブリック/プライベートWebアプリケーション（OCI Flexible Load Balancer にアタッチ）

使用方法(デモ)

検証構成

検証構成図は以下の通りです。
なお、以下リソースは作成済みで進めていきます。

  • AWS上のNW,サーバー

architecture.drawio.png

  • 環境構築コードは以下 GitHub にあげてますので、よかったら覗いてみてください

前提条件

エッジポリシーを使用するにあたり、ドメインの取得が必須となるため、事前にドメインを取得しておく必要があります。

実践

OCI WAF エッジポリシー作成

エッジポリシーを作成します。

OCI コンソール左上のハンバーガーマークをクリックし、Identity & Security → Policies をクリックします。
image.png

Create WAF policy をクリックします。
image.png

このページは Regional WAF の設定画面のため、here をクリックし、エッジポリシーのページに遷移します。
image.png

設定値は以下の通りとし、Create Edge Policy をクリックします。

ポイントは以下の項目です。

  • Primary domain: Edge PoP で稼働するWAFサーバーのFQDN。ユーザーからは、このドメイン名を名前解決する
  • URI：WAFサーバーからリクエストを転送するオリジンサーバーのFQDN。GIPでも可能

GIPを指定するケースとしては、元々オリジン側で使ってたFQDNをWAFサーバー側で使うときに利用すると考えています

image.png
image.png
image.png

  • HTTPS port HTTP port はWAFサーバーからオリジンにリクエストを送信する際に使用する宛先ポートです
  • WAFサーバーの受付ポートではありません。WAFサーバーの受付ポートは 80,443 で固定です

Status が Active になれば作成完了です。
image.png

続いて、WAFサーバーにアクセスするための CNAME レコードをドメインに登録します。
先程作成したポリシーをクリックします。
image.png

画面上部に CNAME が表示されているので、ひかえておきます。
image.png

本環境では、Route 53を利用しているので、以下の用に登録します。
レコード名は、エッジポリシー作成時の Primary domain に合わせ、RDATAは先程ひかえた値を登録します。
image.png

続いて、WAFサーバー用サーバー証明書を、WAFサーバーに登録します。
オリジンが HTTP で稼働していれば不要ですが、今回の検証では HTTPS で稼働させているため設定していきます。
作成したエッジポリシーページの Settings → General settings → Edit をクリックします。
image.png

Enable HTTPS support にチェックを入れ、WAFサーバー用サーバー証明書及び秘密鍵ファイルをアップロードし Save changes をクリックします。
今回は自己署名証明書のため「Self signed certificate」にもチェックを入れています。

  • アップロードするサーバー証明書と秘密鍵は PEM 形式である必要があります
  • ここでアップロードする証明書の CN SAN は Primary domain で設定したFQDNと同一である必要があります

image.png

  • 元々通信フローとして、クライアントからのリクエストは一旦WAFサーバーで終端し、WAFサーバーから改めてオリジンにリクエストする動きとなります。その際のプロトコルはエンドツーエンド(クライアント→オリジンサーバー)で変わりません
  • つまり、WAFサーバーにHTTPでリクエストすればオリジンにもWAFサーバーからHTTPでリクエストし、WAFサーバーにHTTPSでリクエストすればオリジンにもWAFサーバーからHTTPSでリクエストします
  • ちなみに、WAFサーバーはデフォルトでHTTP(80番ポート)でしか受け付けません
  • 上記設定を有効化することで、WAFサーバーがHTTPS(443ポート)で受付けることを可能とします

現状ではWAFサーバーに反映ができていないので、画面上部にある Publish all をクリックします。
image.png

変更には時間を要す旨の確認画面が表示されるので Publish all をクリックします。
image.png

60 分くらいかかってあせりました。。。
Edge PoPの全てのWAFサーバーに反映するためかなり時間を要しますね

動作確認
  • エッジポリシーに登録したWAFサーバー用証明書の署名に使ったCA証明書は、事前にPCへインストールしています
  • オリジンサーバー用証明書の署名に使ったCA証明書は、PCにインストールしていません

curl コマンドで確認していきます。
WAFサーバー経由で、オリジンにアクセスできていることが確認できますね。

$ curl -L -i -v https://www.example.com # Pimary domain で指定したFQDN
* Host www.example.com:443 was resolved.
* IPv6: (none)
* IPv4: 192.29.39.48, 192.29.39.51, 192.29.39.162
*   Trying 192.29.39.48:443...
* Connected to www.example.com (192.29.39.48) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: O=Global example.com Org; CN=www.example.com
*  start date: Jan 18 00:27:17 2026 GMT
*  expire date: Jan 18 00:27:17 2027 GMT
*  subjectAltName: host "www.example.com" matched cert's "www.example.com"
*  issuer: O=Global WAF example.com Org; CN=Global WAF Root CA
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://www.example.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: www.example.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: www.example.com
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/2 200 
HTTP/2 200 
< content-type: text/html; charset=UTF-8
content-type: text/html; charset=UTF-8
< last-modified: Sun, 18 Jan 2026 03:32:19 GMT
last-modified: Sun, 18 Jan 2026 03:32:19 GMT
< content-length: 642
content-length: 642
< accept-ranges: bytes
accept-ranges: bytes
< x-zen-fury: 60de5b120b561f8ac87a194c9199ff9bf8f606d8
x-zen-fury: 60de5b120b561f8ac87a194c9199ff9bf8f606d8
< x-cache-status: NOTCACHED
x-cache-status: NOTCACHED
< server: ZENEDGE
server: ZENEDGE
< etag: "282-648a138c2f492"
etag: "282-648a138c2f492"
< date: Sun, 18 Jan 2026 04:37:53 GMT
date: Sun, 18 Jan 2026 04:37:53 GMT
< x-cdn: Served-By-Zenedge
x-cdn: Served-By-Zenedge
< 

<html><head></head><body><pre><code>
ip-10-0-1-23.ap-northeast-1.compute.internal

NAME="Amazon Linux"
VERSION="2023"
ID="amzn"
ID_LIKE="fedora"
VERSION_ID="2023"
PLATFORM_ID="platform:al2023"
PRETTY_NAME="Amazon Linux 2023.10.20260105"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2023"
HOME_URL="https://aws.amazon.com/linux/amazon-linux-2023/"
DOCUMENTATION_URL="https://docs.aws.amazon.com/linux/"
SUPPORT_URL="https://aws.amazon.com/premiumsupport/"
BUG_REPORT_URL="https://github.com/amazonlinux/amazon-linux-2023"
VENDOR_NAME="AWS"
VENDOR_URL="https://aws.amazon.com/"
SUPPORT_END="2029-06-30"
</code></pre></body></html>
* Connection #0 to host www.example.com left intact

おわりに

本記事では、OCI WAF エッジポリシーについてと、使用方法についてまとめました。
OCI 上でWebアプリケーション（OCI Flexible Load Balancer利用構成）を構築するのであれば、Regional WAF で問題ないかと思いますし、他クラウドであれば各クラウドのサービスを使うのがベストだと考えます。
ただ、オンプレミス上のパブリックWebアプリケーションを迅速に保護したいときなどは導入が簡単なので、一つの選択肢としては有りかなと考えます。

🌟この記事が誰かの役に立てば幸いです！
また、ご質問やフィードバックもお待ちしています。

番外編

Webアプリケーション側の通信制御

エッジポリシーを利用する場合、オリジンとなるWebアプリケーションは、Edge PoPにあるWAFサーバーからのアクセスとなります。
そのためセキュリティの観点から、オリジン側のイングレスとしてWAFサーバーのCIDRからのみに制限するのがベストです。
WAFサーバーのCIDRは以下ドキュメントに記載されています。

オリジンをFQDNで指定する場合は、該当レコードの名前解決ができていることが条件

オリジンは GIPアドレス / FQDN のどちらかで指定しますが、FQDNの場合は、名前解決ができないと作成できません。
なお、GIPアドレスの場合は特に制約なく作成できます。
image.png

参考資料

リファレンス

ブログ

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?