Azure Front Doorのバックエンド正常性について確認してみた

 

Azure Front Doorのバックエンド状態(正常に応答しているかどうか)の確認をしてみました。

また、Azure  Monitorの機能を利用してバックエンドの状態が異常な場合に検知するようにしてみました。Azure Monitorを使ってますのでメール送信等を行う事も標準機能で出来ます。

1.Azure Front Doorのメトリックで正常性プローブの応答率がわかる

マイクロソフト様のサイトを確認するとAzure Front Doorのメトリックで、バックエンドへの正常性プローブの応答率がわかるそうです。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-diagnostics

※マイクロソフト様のサイトでは、バックエンドの正常性の割合と記載されています。

実際にAzure Portal上で確認してみました。

メニューのメトリックを選択すると、下記画面が表示されます。ここでBackend Health Percentageを選択するとバックエンドプール全体での応答率(正常な割合)が表示されます。

応答率になるので、バックエンドプールに所属するバックエンドがすべて正常な場合は100%になります。

※バックエンド落としてないにも関わらず、なぜか100%になってなかったりするので、この編は調査が必要かも。という感じです。

バックエンドホスト単位で確認するには、フィルターの追加を使います。

フィルターの追加を選択すると、BackendとBackend Poolが表示されますので、Backendを選択します。そうすると、値の部分に設定しているバックエンドホスト名が表示されます。確認したいバックエンドのホスト名を選択します。

選択するとバックエンドホスト単位での応答率が確認できました。

ここの数値が低い場合は、バックエンドホストがAzure Front Doorの正常性プローブに応答を返せてないという状態になります。

2.Azure Front Doorのバックエンドの応答がない場合にAzure Monitorで検知する

Azure MonitorでAzure Front Doorのメトリック監視が実現出来ました。

まず、Azure Front Doorのメニューで、警告を選択します。表示された画面で新しいアラートルールを選択します。

そうすると、下記画面が表示されますので、条件を選択します。(Azure Monitorの設定か言った場合はリソースの所で、今回設定するFront Doorを選択します。)

   以下の画面が表示されますので、Backend Health Percentageを選択します。

そうするとシグナルロジックの構成画面が表示されます。ここで実際の設定を行います。

    • バックエンドホスト、バックエンドプールすべて監視する
    • しきい値は95%より小さい場合はアラートを発生させる
    • 15分単位での確認とする(15分単位の平均値で表あk)

上記のような設定の場合は、下記のような画面になります。

バックエンドホスト単位、バックエンドプール全体の状態どれを監視するかを選択します。

個別に設定可否を判断する場合は、ディメンションで対象を選択します。すべてを選択する場合は、選択にチェックを入れるとすべての項目が選択されます。

※注意点ですが、選択にチェックを入れるとAzure Front Door側でバックエンドやバックエンドホストを追加すると自動的に監視項目にも追加になります。

何%以下(より小さい)というしきい値を設定すると、バックエンドホスト側へのアクセスに問題がある場合、Azure Monitorで検知ができます。

上記設定が終わったら、完了をクリックします。

アクショングループや、名前等を付けて保存すれば、Azure Monitorでの監視設定が完了になります。

3.Azure Monitorで実際に送信されたメール

実際にアラートメールを送信すると、以下のような内容が記載されたメールが送信されます。

Metric name BackendHealthPercentage
Metric namespace frontdoors/フロントドア名
Dimensions

ResourceId = /subscriptions/サブスクリプションID/resourcegroups/リソースグループ名/providers/Microsoft.Network/frontdoors/フロントドア名

ApplicationEndpoint = バックエンドホスト名(1)

ApplicationEndpointPool = バックエンドホスト名(2)

Time Aggregation Average
Period Over the last 15 mins
Operator LessThan
Threshold 95
Criterion Type StaticThresholdCriterion

 

 

 

送信元IPアクセス制限をAzure Front Door+Azure Application Gatewayでやってみた

 

Azure Front DoorのバックエンドプールにAzure Application Gatewayを使用した場合に、送信元IPアクセス制限を試してみました。

実際に実施した内容は以下の2つになります。

    • Application GatewayサブネットのNetwork Security GroupでFront Doorからのアクセスのみに制限する
    • Front DoorのWeb Application Firewallポリシーのカスタム規則でIP制限を行う

Front Doorのアクセス制限はNetwork Security Groupの設定で出来ない為、Web Application Firewallポリシーのカスタム規則で実施しています。

1.Application GatewayサブネットのNetwork Security GroupでFront Doorからのアクセスのみに制限する

まず、Application Gatewayのサブネットに適用しているNetwork Security Groupの受信規則に、Service TagがAzureFrontDoor.Backendの許可設定を追加します。

実際の設定画面は下記のようになります。

その次に、上記許可ポリシーより優先順位が下に、Service TagがInternetからポート80,443のアクセス拒否するポリシーを入れます。

これにより、直接Internetから来るアクセスが拒否され、Front Door経由のアクセスのみが許可されます。

直接、Application Gatewayのドメインへのアクセスを実施すると、このサイトにアクセスできませんというメッセージが表示されます。また、Front Door経由のアクセスをすれば正常にサイトアクセスできます。

2.Web Application Firewallポリシーのカスタム規則でIP制限を行う

Front Door経由のアクセスはすべてAzureFrontDoor.BackendでプールされるIPになります。したがって、Application Gateway側ではアクセス元IPがわからない為、Network Security Groupでの設定が出来ません。

Front Door側で同様の制限を行う必要がありますが、Front Doorのアクセス制限はNetwork Security Groupの設定での制限ができません。

結果、Front Doorに設定されているWeb Application Firewallポリシーのカスタム規則でIP制限を行う事になりました。

特定のIPからのアクセスのみを許可する場合は、以下の設定になります。

    • Web Application Firewallのポリシーを防止にする
    • 特定のIPを含まない場合はトラフィックを拒否する設定をする

※防止にすると必要なアクセスがブロックされる場合もありますので注意して下さい。

Web アプリケーション ファイアウォールのポリシーのメニューで設定の中にあるポリシー設定を選択すると下記画面が表示されます。

設定で防止を選択し保存します。

次に、設定にあるカスタム規則を選択します。カスタムルースの追加を選択するとカスタムルールの追加が表示されます。

 

カスタムルール名、優先度を適時設定した後に、条件を下記設定とします。

    • 一致の種類:IPアドレス
    • 一致変数 RemoteAddr
    • 操作:次の値を含まない
    • IPアドレスまたは範囲:許可するIP
    • 結果 トラフィックを拒否する

これで許可するIPアドレス以外のアクセスをすべて拒否する設定が出来ました。

最後にカスタム規則の保存を行えば、作業が完了です。

 

Azure Front Doorのキャッシュ期間が指定出来るようになったようです

 

Azure Froot Doorのキャッシュ期間が指定できるようになったようです。

下記マイクロソフト様サイトに記載がある通り、今まではランダムとなり指定できませんでした。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-caching

しかし、本日(2020年5月2日)にAzure Portal上で確認した所、キャッシュ期間という項目が追加になっていました。

いつの間にという感じなのですが、キャッシュ期間は最大365日を超える事が出来ませんとの記載がありましたので、最大1年という事のようです。(実際に入力時点の最大値は365日まででした。)

実際に設定してみた所、x-cache: TCP-HITとなったのでキャッシュ自体は有効になっているのが確認できたのですが、設定時間を経過しても同じ結果だったので、期間が有効な状況なのかはもう少し確認が必要でした。

※Front Doorデザイナー>ルーティング規則でキャッシュを有効化にするとこのメニューが表示されます。

WWWなしからWWW付きURLへのリダイレクトをAzure Front Door+Azure DNSでやってみた

 

WWW無しURL(xxxx.com)からWWW付URL(www.xxxx.com)へのリダイレクトをAzure Front DoorとAzure DNSの組み合わせで試してみました。xxxxの部分は自分の環境に合わせて読み替えてください。

Azure DNSでAzure Front Dooorのエイリアス登録、Azure Froot Doorでリダイレクトさせる事によりWWW無しURLからWWW付URLへリダイレクトさせています。

今回の検証で実施した作業は、以下の3つになります。

    • Azure DNSで、@(xxxx.com)のAレコードを作成する。
    • Azure Froot Doorでxxxx.comのフロントエンドを作成する。
    • Azure Froot Doorルーティング規則でリダイレクトの設定を作成

※www.xxxx.comの設定がすべて完了している前提とします。

1.Azure DNSで@(xxxx.com)のAレコードを作成する。

Azure DNSでxxxx.comのレコードを作成します。xxxx.comのゾーンで作業を実施します。

Azure DNS>概要>レコードセットの追加を選択します。そうすると以下の画面が表示されます。

    • 名前:空白
    • 種類:A
    • エイリアスのレコードセット:はい
    • エイリアスの種類:Azureリソース
    • Azure リソース:該当のFroot Doorを指定

を選択し保存します。そうすると、レコードセットが作成されます。

これで、xxxx.comへアクセスが来た場合、Froot Doorへアクセスするようになります。

2.Azure Front Doorのフロントエンドを作成する

xxxx.comを受けるフロントエンドを作成します。

フロントドア>Froot Doorデザイナー>フロントエンドまたはドメインで+(追加)を選択します。そうすると以下の画面が表示されます。

こちらで、カスタムホスト名に、xxxx.comを入力し追加すると、xxxx.comのフロントエンドができます。

なお、この時点でDNSのレコード存在チェックが実施されます。

3.Azure Front Doorのルーティング規則を作成する

xxxx.comをwww.xxxx.comにリダイレクトさせるルーティング規則を作成します。

フロントドア>Froot Doorデザイナー>ルーティング規則で+(追加)を選択します。そうすると以下の画面が表示されます。

 

こちらで、名前は適時設定し、フロントエンドまたはドメインで、先ほど作成したxxxx.comのフロントエンドを選択します。

またHTTP、HTTPSを両方リダイレクトする場合は、受け入れ済みプロトコルでHTTPとHTTPS選択します。

また、リダイレクト設定として以下の内容を選択/入力します。プロトコルは一致要求を選択すると、HTTPはHTTPで、HTTPSはHTTPSでリダイレクトしてくれます。

    • ルートの種類:リダイレクト
    • リダイレクトの種類:Moved(301)
    • プロトコルをリダイレクトします:一致要求
    • 送信先ホスト:置換(www.xxxx.comを入力)

入力したら、追加をクリックします。

最後にフロントドアデザイナーの保存を行い設定が完了です。保存完了後に、xxxx.comへアクセスしたら、www.xxxx.comにリダイレクトされるようになります。

※フロントドアデザイナーの保存をし忘れがちなので、注意しましょう。

Azure Front Doorのキャッシュを更新する

 

Azure Front Doorにはコンテンツキャッシュの機能があります。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-caching

キャッシュの機能を利用する事により、バックエンドプール側の負荷を下げたり、レスポンスタイムの向上が期待できます。

キャッシュ自体は、アクセスされたURLパスを保持します。同じURLに対して2回目のアクセスからキャッシュが使用される動きとなります。

一方で、Front Door自体はバックエンドプール側のサイト更新を能動的に検知する事はありません。

キャッシュされている期間中は、バックエンドプール側でサイトが更新しても実際にアクセスしても反映されない状態になります。

その為、Front Doorでキャッシュを有効にした場合、キャッシュ更新を行う事が必要になります。

1.Azure Froot Doorのキャッシュはクリアだけできる

Azure Front Doorのキャッシュを手動で更新する事は出来ないそうです。

その為、キャッシュを更新するには、以下のように一度キャッシュクリアを行う必要があります。

    1. サイト更新
    2. キャッシュクリア
    3. サイトへのアクセス

Front Doorのキャッシュクリアには、Remove-AzFrontDoorContentコマンドを使用します。

https://docs.microsoft.com/ja-jp/powershell/module/az.frontdoor/Remove-AzFrontDoorContent?view=azps-3.8.0

今回はサンプルで以下のようなPowerShellを作成してみました。(GitHubにも公開しています。)

#Front DoorのキャッシュクリアをするPower Shell

param (
    [String] [Parameter(Mandatory=$true)]  $ResourceGroupName ,
    [String] [Parameter(Mandatory=$true)]  $FrontDoorName ,
    [String] [Parameter(Mandatory=$true)]  $ContentPath
    )

Remove-AzFrontDoorContent -ResourceGroupName $ResourceGroupName -Name $FrontDoorName -ContentPath $ContentPath
| where Category == “FrontdoorWebApplicationFirewallLog”
 

以下のように実行して頂く事で、キャッシュのクリアが可能です。

c:\FrontDoorのキャッシュをクリアする.ps1 -ResourceGroupName “リソースグループ名” -FrontDoorName “フロントドア名” -ContentPath “削除するパス (例:/*)”

サイト更新後に、今回のようなPower Shellを利用してキャッシュクリアする事により、更新したけど反映されないという事が防げるかと思います。

※マイクロソフトサポート様に色々ご教授頂きながら進めさせて頂きました。本当に有難うございます。

Azure Front DoorやWeb Application Firewallのログを取得してLog Analyticsで確認してみた

 

Azure Froot Doorのアクセスログ取得設定およびLog AnalyticsでアクセスログやWeb Application Firewall(Froot Doorに設定した場合)のログ確認をしてみました。

設定にあたっては、マイクロソフト様サイトを参考に進めました。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-diagnostics

1.Azure Froot DoorやWeb Application Firewallのログを取得するのは診断設定

Azure Froot Doorのアクセスログは、診断設定を利用します。これはApplication Gatewayと同じ方法になります。

診断設定を選択すると下記画面が表示されますので、logとmetricにチェックを入れます。今回はLog Analyticsで確認するので、Log Analytics への送信にチェックを入れて、送信先のワークスペース名を指定します。

選択が終わったら、診断設定の名前を付けて保存します。

なお、FrontdoorWebApplicationFirewallLogはFroot DoorでWeb Application Firewallの設定を行っている場合のみ出力されます。

2.Log Analyticsでログの検索を行う。

Froot Doorのメニューの中に、ログという項目があります。この項目を選択すると、診断設定で選択したLog Analyticsのワークスペースが開かれます。

FrontdoorAccessLogがアクセスログになります。以下のようなクエリを利用する事でアクセスログが表示されます。

#アクセスログを表示する

AzureDiagnostics
| where Category == “FrontdoorAccessLog”
 
#アクセスログをアクセス元のIPでカウントする。(アクセス数順で並び変える。)

AzureDiagnostics
| where Category == “FrontdoorAccessLog”
| summarize total_hits = count() by clientIp_s
| sort by total_hits desc
 

Web Application Firewallのログは、FrontdoorWebApplicationFirewallLogになります。

#Web Application Firewallのログを表示する

AzureDiagnostics
| where Category == “FrontdoorWebApplicationFirewallLog”
 

上記検索だとAllowされたLogも表示される為、許可された通信を含むすべてのアクセスログが表示されます。Allow以外のログについては以下のようなクエリで検索可能です。

#Allow以外のアクセスログを表示する

AzureDiagnostics
| where Category == “FrontdoorWebApplicationFirewallLog”
| where action_s != “Allow”
 

また、Web Application FirewallでBlockされたログについては以下のようなクエリで検索可能です。

#Web Application FirewallでBlockされたアクセスログを表示する

AzureDiagnostics
| where Category == “FrontdoorWebApplicationFirewallLog”
| where action_s == “Block”
 

上記クエリを実行すると、どのルールでBlockされたのかもわかります。

3.Froot Doorのバックエンドプール側のアクセスログについては注意が必要

Froot Doorを使う場合ですが、バックエンドプール側のアクセスログに表示されるclientIP_sがFroot DoorのBackend poolのIPアドレスになります。

その為、バックエンドプール側(Virtual Machine等)でアクセス元IPを確認する場合は、x-forwarded-forを確認する必要があります。

また、マイクロソフト様のサイトにも記載がありますが、Froot Doorからのヘルスチェックアクセスが結構な数のアクセスが来るので、アクセスログが大量になる事にも注意が必要です。

【参考】Web Application Firewallの作成は下記に記載しています。

 https://www.tama-negi.com/2020/05/10/azure-web-application-firewall/ ‎

HTTPからHTTPSへリダイレクトをAzure Front Door でやってみた

 

HTTPからHTTPSへのリダイレクトをAzure Front Doorで試してみました。

Azure Front Doorデザイナーのルーティング規則にて、HTTPS用のルーティング規則とHTTP用のルーティング規則を2つ作成し、HTTP用のルーティング規則内でHTTPSへリダイレクトさせる事により実現できました。

1.Azure Front Doorのルーティング規則を作成する(HTTPS用)

まずHTTPS用のルーティング規則を作成します。

Azure Portal上で、Azure Front DoorのFront Doorデザイナーのメニューをクリックします。

デザイナーが表示されますので、その中でルーティング規則で+をクリックし、ルーティング規則を追加します。

受け入れ済みのプロトコルをHTTPSで設定とます。フロントエンドまたはドメインは受信するドメインを選択します。

ルートの種類は、進むを選択し、バックエンドプールは転送先のバックエンドを選択します。設定が終われば保存します。

2.Azure Front Doorのルーティング規則を作成する(HTTP用)

次にHTTP用のルーティング規則を作成します。

まず、受け入れ済みのプロトコルをHTTPとします。フロントエンドまたはドメインは受信するドメインを選択します。

次に、ルートの種類で、リダイレクトを選択します。併せて、転送プロトコルをHTTPSのみにすることにより、HTTPSへのリダイレクトを実現します。

保存すれば設定が完了です。(Front Doorデザイナーの方の保存もお忘れなく。)

Azure Web アプリケーション ファイアウォールのカスタム規則設定をしてみた(国別ブロック)

 

Azure WEBアプリケーションファイアウォール(WAF)で国別ブロックの設定を試してみました。

Azure WEBアプリケーションファイアウォール(WAF)ではカスタム規則の作成が可能です。このカスタム規則で、国別ブロックや特定のIPからのアクセスについてブロックする等の設定ができます。これはApplication Gateway(V1)のWAFでは設定出来ない内容でした。

また、Azure WEBアプリケーションファイアウォール(WAF)は単体利用ではなく、Azure Front Door等組み合わせて利用します。

マイクロソフト様サイトに記載の内容を参考に設定を行っています。

https://docs.microsoft.com/ja-jp/azure/web-application-firewall/afds/waf-front-door-create-portal

今回試してみた、国別ブロックは、カスタムルールで非常に簡単に実現できます。

※WAFで実現できる設定内容は、Application GatewayかFrontDoor(今回)の選択によって異なるようです。

1 .Azure WEBアプリケーションファイアウォールのカスタム規則を作成

WAFの画面で、カスタム規則を選択すると下記画面が表示されます。
カスタムルールの追加をクリックします。

そうるすと、カスタムルールの追加が表示されます。
一致の種類に、geoロケーションを選択すると国コードが表示されます。
国コードを選択すると、プルダウンで国が表示されるので、それを選択するだけです。
1つのカスタムルールで選択できるのは10までになります。

今回は特定の国だけをブロックしたいので、操作は次である(合致するという意味)、結果はトラフィックを拒否するを選択します。
カスタムルール名、優先度を設定し、追加ボタンをクリックすればカスタムルールが出来上がります。

最後に、カスタム規則の画面の保存ボタンをクリックすれば新たに作成したカスタムルールが適用されます。これ押し忘れると、作成したカスタムルールは適用も保存もされません。

Azure Web アプリケーションファイアウォールの作成手順は下記に記載してみました。

hhttps://www.tama-negi.com/2020/05/10/azure-web-application-firewall/

Azure Web アプリケーションファイアウォールを作ってみた