※ 本記事は、Aditya Kulkarniによる”URL Filtering using OCI Network Firewall“を翻訳したものです。

2022年10月17日

​

はじめに:

Oracleは最近、VCN内トラフィック検査、カスタムURL/FQDNフィルタリング、SSL検査などの機能を持つNetwork Firewallサービスを導入しました。これにより、アーキテクチャにおいてきめ細かなアクセス制御を必要とする多くのシナリオへの扉が開かれました。このブログでは、OCI Network FirewallのURLフィルタリング機能に焦点を当て、さまざまなユース・ケースの実装にどのように役立つかを確認します。一般的な概念と実装については、このブログを参照してください。

ユースケース1: NAT Gatewayを介したアップグレード/パッチのみの許可

NATゲートウェイを使用すると、プライベート・サブネット内のリソースがインターネットへの接続を開始できます。主に、パッチ適用/アップグレードを行い、Oracle YUMリポジトリから最新の更新を取得するために使用されます。ただし、これには次が必要です。:

  1. インターネット（0.0.0.0/0）宛のトラフィックをNATゲートウェイに送信するルート・ルール。
  2. エグレス・セキュリティ・ルールでは、インターネットへのすべての通信が許可されます（0.0.0.0/0）

ご覧のとおり、これらのルールでは、Oracle Yumリポジトリとともにサブネットからインターネット上のすべてへの接続を開始できます。一部の顧客はセキュリティ要件が厳しく、インターネットに出るすべてのものを許可することを躊躇しています。つまり、Oracle Yumリポジトリは複数のIPアドレスでホストされており、予告なく変更される可能性があります。そのため、これらのIPを追跡してセキュリティ・リストに手動で追加することは面倒です。

また、セキュリティ・リストには、URL/FQDNに基づいてトラフィックを許可/拒否する機能がありません。OCI Network FirewallのURLフィルタリング機能を使用すると、お客様はOracle Yumリポジトリへのトラフィックのみを許可し、他のすべてのものを拒否できます。

構成:

NATGW

Network Firewallは別のサブネットに配置されます。ルート・ルールは、図に示すように構成されます。

ネットワーク・ファイアウォール・ポリシーを作成するには、「Identity and Security」→「Firewalls」→「Network Firewall Policies」に移動し、新しいポリシーを作成します。

基本情報を追加した後、

  • PhoenixリージョンのOracle YumリポジトリのURLを追加します。すべてのリージョンのURLを取得できます: https://docs.oracle.com/iaas/Content/General/Concepts/addressranges.htm
  • リソースがIPアドレス・リストにあるプライベート・サブネットのCIDRブロックを追加します。より細かくしたい場合は、/32表記を使用して個々の仮想マシンIPアドレスを追加することもできます。
  • ルールで、URLが’yum-us-phoenix-1.oracle.com’と一致する場合にのみプライベート・サブネットのCIDRブロックがインターネットに到達することを明示的に許可するセキュリティ・ルールを追加します。

「Create」をクリックします。ポリシー構成は次のようになります。:

NAT_configuration_1
NAT_configuration_2

検証:

仮想マシンから、

google.comへのアクセスを試みます。:

NAT_Verification_1

サブネットにルート・ルールおよびセキュリティ・ルールがあり、すべてを許可している場合でも、接続は予期したとおりに失敗します。つまり、ネットワーク・ファイアウォール・ポリシーが機能しているということです。

Oracle Yumリポジトリへの問合せを試みます。:

NAT_Verification_2

Oracle Yumリポジトリからパッケージを正常にダウンロードできます。!

ユースケース2: URLフィルタリングを使用したアプリケーションへのアクセスの制限

多くの場合、外部ユーザーがパブリック・インターネットからアクセスできるパブリック対応アプリケーションをホストします。お客様は、セキュリティ・リストの宛先ポートに基づいてアクセスを制限することを選択できますが、リクエスト内のURLを制御することはできません。

URLフィルタリングでは、セキュリティ・ルールでURL一致が見つかった場合のみ、アプリケーション宛てのリクエストを許可できます。他の仮想マシン/IPまたはその他のURLへのリクエストは拒否されます。

構成:

Public Facing Application

パブリック対応アプリケーションは132.226.117.114でホストされ、マシンにmy.webapp.comを解決するDNSエントリがあります。アプリケーション・サブネットへのアクセスを制限するために必要なセキュリティ・ルールは1つのみです。他のトラフィックはすべて拒否されます。

ネットワーク・ポリシー構成:

IGW_configuration_1
IGW_configuration_2

検証:

ローカルPCからのURL ‘my.webapp.com’でのリクエスト:

IGW_Verification_1

ローカルPCからのパブリックIPでのリクエスト:

IGW_Verification_2

ユースケース3: パブリック・インターネットへの選択的なアクセス制御

パブリック・インターネットへのアクセスを必要とするサブネット内に複数の仮想マシンが存在するシナリオについて考えます。顧客は、0.0.0.0/0のルート・ルールを追加し、セキュリティ・リストに0.0.0.0/0をエグレスとして追加する必要があります。一部の仮想マシンが特定のWebサイトにアクセスできないようにしたい場合もあります。さらに、インターネットのWebサイトへの異なるレベルのアクセスを必要とする様々なVMセットが存在する場合があります。例えば、一部の機械はゲーム用ウェブサイトにアクセスすべきではなく、ソーシャルメディアにアクセスすべきであり、すべてが教育用ウェブサイトにアクセスできるようになっているべきです。これは、URLフィルタリングを使用して実現できます。

構成:

Custom

この図では、仮想マシン1はwww.google.com以外のすべてのものにアクセスできる必要があります。同様に、仮想マシン2はwww.yahoo.com以外のすべてのものにアクセスできます。ここに示すVMはパブリック・サブネットにありますが、プライベート・サブネットにも存在できます。また、特定のトラフィックを拒否することを選択するため、すべてを最後に明示的に許可する必要があり、ルールの順序が重要であることに注意してください。最後にそのルールを追加しない場合、一致するルールがない場合、ネットワーク・ポリシーはデフォルトですべてを拒否します。

ネットワーク・ポリシー構成:

Custom_verification_1
Custom_verification_2
Custom_verification_3

検証:

仮想マシン1（10.0.0.28）から:

Custom_test_1

仮想マシン2（10.0.0.13）から:

Custom_test_2

仮想マシン1はwww.google.comに到達できません。仮想マシン2はwww.yahoo.comに到達できませんが、インターネットの残りの部分に到達できます。

まとめ:

結論として、OCIネイティブNetwork FirewallのURL/FQDNフィルタリング機能を使用すると、より詳細なレベルでアクセス制御ポリシーを管理できます。この機能が有益な様々なユースケースを検討しました。セキュリティを損なうことなく、お客様がネットワーク・ソリューションをより適切に設計できるよう支援します。