今回はAuto-Tagについて紹介します。
一般的にローカルブレイクアウトというとSD-WANをイメージされる方が多く、ローカルブレイクアウトのためだけにFWとは別にSD-WAN装置を導入されているユーザーも見受けられますが、実はPAシリーズのAuto-Tagを利用することでコストを掛けずにローカルブレイクアウトを行うことが可能です。
Auto-Tagに関する公式サイトのリンク
Auto-Tag でできるローカルブレイクアウト
Auto-Tagとは
まずAuto-Tagについて簡単に説明します。Auto-Tagはログ転送(Log Forwarding)設定の中の「Built-in Actions」によって実現します。PAシリーズではトラフィックログや脅威ログ、URLフィルタリングログを転送先毎に詳細にフィルタリングすることが可能です。
「Built-in Actions」はこのフィルタリングされたログの送信元/宛先 IPアドレスに対してタグを付与(または除去)することのできる機能です。
そして、タグが付加されたIPアドレスは、ダイナミックアドレスグループで収集することが可能です。結果としてタグが付加されたIPアドレス群を1つのアドレスグループとして各種ポリシーで利用することができます。
このように、PAから出力されるログを利用してアドレスグループを自動生成することができます。
Auto-Tagの設定方法
Auto-Tagによるローカルブレイクアウトの設定方法です。
今回は、トラフィックログの中からアプリケーション名「ms-office365-base」でアプリケーション識別された通信の宛先IPアドレスに対してタグ付けを行いたいと思います。
Tagの作成
タグ付けを行うための「MS-365」というタグを作成します。
【OBJECTタブ】→【Tags】をクリックし、画面下の「Add」をクリックして、以下のタグを作成します。
- Name:MS-365
- Color:オプション
- Comments:オプション
Log Forwarding Profileの設定
【OBJECTタブ】→【Log Forwarding】をクリックします。(※ 既存で設定したLog Forwarding Profileをそのまま利用したい場合は、そのProfileに設定を追加してください)
「Log Forwarding Profile」の名前を設定し、ウィンドウ下の「Add」をクリックします。
「Log Forwarding Profile Match List」ウィンドウが開くので以下の設定を行います。
- Name: 名前の設定
- Log Type: traffic
- Filter:右側の「∨」をクリックすると表示される「Filter Builder」をクリックします。
- Connecctor:and(条件)を選択
- Attribute:Application を選択
- Operator:equal を選択
- Value: ms-office365-base と入力
- Addボタンをクリック
- Addを押すと上部のウィンドウに自動的にフィルタ条件が入力されます。Filter Builderでは、このようにメニュー形式でフィルタを作成することができます。(フィルタを直接編集することもできます。)
- 上部「View Filtered Logsタブ」をクリックします。
今回のフィルタ設定で、実際にどのような通信がフィルタできているかを確認することができますので、想定通りにフィルタリングができているかを確認してください。問題無ければ、OKを押して設定を保存してください。
(この画面上で、通常の【MONITORタブ】→【Traffic】でフィルタするのと同様の手順(クリックベース)でフィルタを作成することも可能です。)
- OKを押すと「Log Forwarding Profile Match List」の画面に戻ってきます。「Filter」の部分に先ほどのフィルタ設定が反映されています。ここまで設定が完了したら、タグを付与するための「Built-in Actions」設定を行います。右下の「Add」をクリックします。
- 以下のようにBuilt-in Actionを設定して「OK」をクリックします。
- Name:Add-Tag_MS-365
- Target:Destination Address(今回はMS-365の宛先IPを収集したいので)
- Action:Add Tag(タグの付与)
- Registration:Local User-ID(今回はPA内部で利用するため)
- Timeout(min):60(最大43200分(30日)まで設定可能)
- Tags:MS-365(複数のタグを同時に設定可能)
- Log Forwarding Profile Match List にBuilt-in Actionが設定されていることを確認して「OK」をクリックします。
- Log Forwarding Profile にBuilt-in Actionが設定されました。「OK」をクリックします。
セキュリティポリシーへのLog Forwarding Profileの適用
Auto-Tag機能は出力されたログに対する動作になりますので、セキュリティポリシーに上記で作成したLog Forwarding Profile を適用する必要があります。セキュリティポリシーの詳細設定については記載しませんが、今回は以下のようなInternet向けのポリシーにLog Fowarding Profileを適用します。
- ポリシー名(今回はINTERNET)をクリックします。
- 「Actionsタブ」をクリックし、先ほど作成したLog Forwarding Profileを適用して、「OK」をクリックします。
ここまでの設定で、「ms-offic365-base」と識別されたトラフィックログの宛先IPアドレスにタグ「MS-365」を付与する設定は完了しました。次はこのタグのついた宛先IPアドレスを収集するダイナミックアドレスグループの設定を行います。
Dynamic Address Groupの設定
【OBJECTS タブ】→【Address Groups】を選択し、画面下の「Add」をクリックします。
- Name:MS-365
- Description:オプション
- Type:Dynamic (ダイナミックアドレスオブジェクトの設定)
- Match:Add Match Criteria をクリックするとタグのリストが表示されるので、MS-365のタグの右側にある「+」ボタンをクリックします。「’MS-365’」が登録されます。
- Tags:空欄のまま
「OK」を押してAddress Groupを設定します。
なお、FWリソースを無駄遣いしないようにするため、ダイナミックアドレスグループを作成するだけではアドレスの取り込みは行われません。実際にポリシーなどに適用して初めて取り込みが行われます。
Policy Base Forwardingの設定
Policy Base Forwarding(PBF)の設定を行います。
【POLICIES タブ】→【Policy Based Fowarding】を選択して画面下の「Add」をクリックします。
- General タブ
- Name:MS-365
- Source タブ
- Zone;Trust
- Source Address:ANY
- Source User:ANY
- Destination/Application/Service タブ
- Destination Address:MS-365(作成したダイナミックアドレスグループ)
- Application:ANY
- Service:ANY
- Forwarding タブ
- Action:Forward
- Egress Interface:eth1/4(副回線のIF)
- Next hop:IP Address
- 10.0.40.1(副回線のGW IPアドレス)
- Monitor:任意(Pingによる疎通確認を行いうことで、GWの先の障害など、副回線のIFがリンクダウンせずに発生する通信障害時に、このPBF設定を無効化することが可能です。)
ここまで設定が完了したらCommitを行います。
Auto-Tagの動作確認
FW配下のクライアントPCからMicrosoft 365にアクセスします。
【MONITOR タブ】→【Traffic】でトラフィックログを確認します。
- 「ms-office365-base」でアプリケーション識別されている通信があることを確認します。
- 宛先IPアドレスは「20.190.141.35」になっています。
【MONITOR タブ】→【IP-Tag】でタグ付けされたIPアドレスを確認します。
- IPアドレス「20.190.141.35」に対して、「MS-365」というタグが付加(register)されていることを確認します。
【OBJECTS タブ】→【Address Groups】を選択します。
- 作成したアドレスグループ「MS-365」のADDRESSES欄の「more…」をクリックします。
- アドレスグループ「MS-365」に、Auto-Tag機能によって「MS-365タグ」が付与された宛先IPアドレス「20.190.141.35」が取り込まれていることが分かります。
結果として先ほどPBFの宛先IPアドレスとして設定したダイナミックアドレスグループ「MS-365」に「20.190.141.35」が設定されたことになりますので、これ以降タイムアウトするまで、20.190.141.35宛の通信はPBFにより副回線(eth1/4)経由で転送されることになります。
このように、Auto-Tag機能を利用することで、App-IDによるアプリケーション識別情報(のログ)を元に宛先IPアドレスを自動的に収集してローカルブレイクアウトを行うことができます。
補足
色々なログ情報を元にAuto-Tagを利用できます
今回はトラフィクログのApplication情報を利用しましたが、それ以外にも例えば
- URLフィルタリングログのURL情報(特定のドメインだったら副回線を利用する。)
- URLフィルタリングのURLカテゴリ情報(Gameカテゴリだったら副回線を利用する。)
- App Container情報(ms-office365だったら副回線を利用する。)
- 今回は分かりやすくするために「ms-office365-base」を利用してローカルブレイクアウトを行いましたが、PAシリーズにはms-office365に関するアプリケーションは大量に登録されていて、これらは「ms-office365」というアプリケーションコンテナに纏められています。一般的には、「ms-office365関連の通信をローカルブレイクアウトしたい。」ということが多いと思いますが、今回のようにApplicationログを利用してPBFを行う場合、対象となるすべてのアプリケーションをLog Forwarding Profileに登録する必要がでてきますし、新たなms-office365関連アプリケーションが追加された場合も個別に対応する必要があります。
アプリケーションコンテナ ログを利用することで、これらを一括で登録できるだけでなく、新たなms-office365関連のアプリケーションが追加されたとしてもそのまま利用できる利点があります。
- 今回は分かりやすくするために「ms-office365-base」を利用してローカルブレイクアウトを行いましたが、PAシリーズにはms-office365に関するアプリケーションは大量に登録されていて、これらは「ms-office365」というアプリケーションコンテナに纏められています。一般的には、「ms-office365関連の通信をローカルブレイクアウトしたい。」ということが多いと思いますが、今回のようにApplicationログを利用してPBFを行う場合、対象となるすべてのアプリケーションをLog Forwarding Profileに登録する必要がでてきますし、新たなms-office365関連アプリケーションが追加された場合も個別に対応する必要があります。
など様々な方式でAuto-Tagを利用可能です。
最初の通信は主回線を経由します。(重要)
Auto-Tag機能を利用したローカルブレイクアウトでは、序盤の通信は主回線を通ります。これは最初の通信が「ms-office365-base」と識別され、このセッション終了後にログが出力されることによって、初めてこのログ情報を元にしたAuto-Tag機能が動作するためです。
たとえば副回線に設定されたIPアドレスで送信元NATなどを行っていて、このIPでしかアクセスできないフィルタリングをアクセス先のクラウド側で実施しているような場合、最初の通信が主回線経由で送信され・・・クラウド側でブロックされ・・・3ウェイハンドシェイクすら完了せず・・・十分なパケットが流れないのでアプリケーション識別できず(Incomplete)・・・結果としてAuto-Tagが機能せず主回線経由でパケットが送信され続け・・・ドロップされ続ける・・・という事態になる可能性もあります。Auto-Tagの利用に際しては、この辺りの動作原理を理解した上でご利用いただくことで、トラブルを回避できるのではないかと思います。
Auto-Tagとは異なり外部サーバとの連携が必要になりますが、以前紹介したEDLを使ってもローカルブレイクアウトは可能です。特にAWSやMS365など、利用するアドレスレンジが公開されているものについては、EDL Hosting Serviceでも収集可能です。
Auto-Tag機能は、FW単体で完結したかたちでローカルブレイクアウトだけでなく、隔離や認証など様々なシチュエーションで利用できるとても便利な機能なのでいろいろと活用いただければと思います。(面白い利用方法があれば、記事にしますのでコメント教えてください)
コメント欄 質問や感想、追加してほしい記事のリクエストをお待ちしてます!