こんにちは。SCSKの山口です。
先日、あるアーティストのライブに当選したのですが、当選通知＆料金支払いのメールが迷惑メールフォルダに入っていて、せっかくの強運が危うくオジャンになるところでした。
メールのフィルタリング基準が気になって少し調べたのですが、URL等が含まれているメールだとフィッシングを疑われてしまい、迷惑メールと判断されることがあるそうです。
しっかりと守ってくれていることはいいことですが、過保護すぎて必要なものまでブロックされてしまうのは考え物ですね。
「URLが含まれてるから怪しいメールだけど、コイツこのライブ申し込んでたから必要なメールだ。仕方ねえ通してやるか。」みたいな判断をしてくれたらいいのに。と感じました。
いきなり何の話だと皆さん思っているころだと思いますが、先日業務でも似た（？）ような場面がありました。
| 通信要件：インスタンスからの下り通信を全拒否したいが、特定のURLへの通信だけは許可したい |
|---|
要するに、IPアドレス制御で下り通信を全拒否しつつ、FQDN制御で特定サイトへのアクセスを許可する。ということです。
さらに嚙み砕くと、「外部のサイトは危険なものも多いから、アクセスできないようにする」かつ「特定のサイトだけは通信ができるようにする」ということです。
二段階で噛み砕きましたが、全然要約できていない気がするので、次章から詳しく書いていきます。
実現したいこと
今回実現したいことを図式化します。
①GCEからの下り通信を全拒否（IPアドレスで制限）
こちらはファイアウォールルールを設定することで簡単に実現可能ですね。
②特定のURL（https://xxxx.jp）への通信を許可
問題はこっちです。Google Cloud のVPCファイアウォールルールでは、「IPアドレスによる制御」のみが可能です。FQDNによる制御は出来ません。
FQDNによる制御は、ファイアウォール ポリシー ルールを使用することで実現することができます。
今回は、すでにFWルール（IPアドレス制御）がある状態で、新たにFWポリシールール（FQDN制御）を作成し、合わせ技で要件を実現してみます。
ファイアウォール ポリシー ルール
概要については、今回使用する部分のみ簡単に説明します。
詳細については下記ドキュメントをご参照ください。
参考資料
ファイアウォール ポリシー：https://cloud.www.google.com/firewall/docs/firewall-policies-overview?hl=ja
FWルールとFWポリシールールの評価順序
前述したとおり、今回はFWルールとFWポリシールールの合わせ技になります。（名前がややこしいですがついてきてください。。。）
そのため、両者の評価順序が非常に重要になります。
デフォルト状態での評価順序は以下の通りです。上から下の順序で評価されます。
| ①階層型FWポリシールール
①-1 プロジェクトを含む組織レベル ①-2 プロジェクトから最も遠い（上位）フォルダレベル ①-3 プロジェクトに近い次のフォルダレベル ②VPC FWルール ③ネットワークFWポリシールール ③-1 グローバルネットワークのFWポリシールール ③-2 リージョンネットワークのFWポリシールール ④暗黙のFWルール（上り全拒否＋下り全許可） |
図にすると以下の通りです。
実践①：FWルールとFWポリシールールの合わせ技による通信制御
改めて、要件を整理します。
| 要件①：GCEからの下り通信をすべて拒否する
要件②：特定のURLへの下り通信のみ許可する |
今回は要件②で使用するFQDNとして「www.google.com」を使用します。
環境準備
下記環境を用意します。
要件①：GCEからの下り通信をすべて拒否する
下記FWルールを作成します。
| FWルール名称 | yamaguchi-egress-deny-all |
|---|---|
| 説明 | GCEからのすべての下り通信を拒否 |
| ネットワーク | vpc-test-yamaguchi |
| 優先度 | 65534 |
| 方向 | 下り（内向き） |
| 一致した時のアクション | 拒否 |
| ターゲットフィルタ | IP範囲：0.0.0.0/0 |
| プロトコルとポート | all |
これによって、GCE（gce-test-yamaguchi）からのすべての下り通信が拒否されるはずです。
試しにwww.google.comへの疎通確認をしてみます。
pingを打っても応答がありません、下り通信が正常にブロックされているようです。
要件②：特定のURL（www.google.com）への下り通信のみ許可する
次に、FWポリシールールを使用して、www.google.comへの通信を許可します。
下記FWポリシーを作成します。
| FWポリシー名称 | fwpolicy-test-yamaguchi |
|---|---|
| 説明 | （省略） |
| デプロイのスコープ | リージョン |
| リージョン | asia-northeast1(東京) |
| ※1 ルールの追加 | なし（デフォルトで設定されるルール削除） |
| ※2 ポリシーと VPC ネットワークの関連付け | vpc-test-yamaguchi |
※1 ルールの追加
・この項目でFWポリシールールを作成することもできます。今回は説明のためにFWポリシーのみをまず作成し、その後ポリシーに含めるルールを作成します。
※2 ポリシーと VPC ネットワークの関連付け
・FWポリシーはVPCに関連付けることができます。今回は「vpc-test-yamaguchi」に関連付けます。
作成したFWポリシーを見てみましょう
FWポリシールールを作成しなかったので、デフォルトのポリシールールのみが表示されています。
デフォルトのポリシールールでは、上り/下りの通信を全て「次に移動」するルールがIPv6とIPv4で設定されています。
FWポリシーでは、「許可/拒否」に加えて「次に移動」のアクションが用意されています。それぞれ以下のように動きます。
| 許可 | トラフィックを通す（階層が下位のルールは見ない） |
|---|---|
| 拒否 | トラフィックを通さない（階層が下位のルールは見ない） |
| 次に移動 | 階層の下位のルールに評価を委ねる |
つまり、「次に移動」では「ここでは評価しないけど、次で決めてもらって。」みたいに次に当たるルールに判断を任せる動きをします。
では、作成したFWポリシーに「www.google.com」へのアクセスを許可（次に移動）するルールを作成していきましょう。
FWポリシーの詳細画面（上図）の「+ルールを作成」のボタンから作成することができます。
| 優先度 | 2147483640 |
|---|---|
| 説明 | www.google.comへの下り通信を許可（TCP/443,ICMP） |
| トラフィックの方向 | 下り |
| 一致した時のアクション | 許可 |
| ログ | オフ |
| ※1 対象 | サービスアカウント |
| サービスアカウントのスコープ | このプロジェクト内 |
| ターゲットサービスアカウント | Compute Engine default service account |
| 宛先 | FQDN：www.google.com |
| 送信元 | 10.20.30.0/24 |
| プロトコルとポート | 指定したプロトコルとポート |
| TCP | ポート：443 |
| その他 | icmp |
※1 対象
FWポリシールールでは、ターゲット（対象）に「ネットワークタグ」を使用することができません。
代わりに、「ターゲットVPCネットワーク」もしくは「ターゲットサービスアカウント」を使用する必要があります。
今回は、「ターゲットサービスアカウント」を使用しています。
参考資料：https://cloud.google.com/vpc/docs/using-firewall-policies?hl=ja#limitations
では、この状態でwww.google.comへpingを飛ばしてみましょう。
おや？？？www.google.comへのicmp通信を許可するポリシールールを作成したのに通信ができませんね。
タネ明かしは次の章で行います。
再掲：FWルールとFWポリシールールの評価順序
初めの方に述べた、「FWルールとFWポリシールールの評価順序」の図をもう一度貼ります。
一番下の段に注目です。
評価順序が、「② VPC FWルール → ③ ネットワークFWポリシールール」となっています。
つまり、今回の要件では先に「GCEからの下り全拒否」のFWルールが適用されてしまっているため、その後の「www.google.com」への許可ルールが意味をなしていません。
じゃあ要件みたせないじゃん、、、となりそうですが、なんとこの評価順序を変更する方法があります。次の章で説明します。
実践②：FWポリシールール適用順序変更
下記のコマンドを実行することで、FWルールとFWポリシールールの評価順序を入れ替えることができます。
|
コマンド |
|---|
| gcloud compute networks update VPC-NETWORK-NAME \
–network-firewall-policy-enforcement-order BEFORE_CLASSIC_FIREWALL(AFTER_CLASSIC_FIREWALL) |
FWポリシー適用順序変更コマンドでの適用順序の変化
| 1.デフォルト状態 | ① 階層型FWポリシールール
② VPC FWルール ③ ネットワークFWポリシールール ④ 暗黙のFWルール（上り全拒否＋下り全許可） |
| 2.以下を実行
gcloud compute networks update VPC-NETWORK-NAME \ –network-firewall-policy-enforcement-order BEFORE_CLASSIC_FIREWALL |
① 階層型FWポリシールール
② ネットワークFWポリシールール ③ VPC FWルール ④ 暗黙のFWルール（上り全拒否＋下り全許可） |
| 3.以下を実行
gcloud compute networks update VPC-NETWORK-NAME \ –network-firewall-policy-enforcement-order AFTER_CLASSIC_FIREWALL |
① 階層型FWポリシールール
② VPC FWルール ③ ネットワークFWポリシールール ④ 暗黙のFWルール（上り全拒否＋下り全許可） ⇒デフォルト状態に戻る |
先ほどの実践①の環境でこのコマンドを実行します。
プロンプトが塩対応で適用できているか不安ですが、再度pingを飛ばしてみます。
応答が返ってきました。大成功です。
他のURL（FQDN）へのアクセスはというと
想定通り拒否されていますね。大成功です。
適用順序をもとに戻して再度www.google.comへpingを投げてみましょう。
想定通り、通信できなくなりました。大成功です。
実践①、実践②で試した方法を使うことで、「インスタンスからの下り通信を全拒否したいが、特定のURLへの通信だけは許可する」という要件を満たすことができました。
まとめ
今回は、「インスタンスからの下り通信を全拒否したいが、特定のURLへの通信だけは許可したい」という要件を、FWルールとFWポリシールールの合わせ技で実現してみました。
今回はインスタンスからの下り通信を全拒否をあらかじめFWルールで実装しました（ちょうどその環境があった）が、初めから今回のような要件が見えている場合は、ルールを作成する際に「FWポリシーの作成」の中にすべて吸収させた方が良いと感じました。
そうすることで、作成時の混乱を避けることができますし、管理やメンテナンスがより簡単になると思います。
今後の教訓にしたいと思います。