いつの間にかがっつり進化してた

Azureに触れるきっかけにもなったAzureCDN。Azureリソースの中でも有数の激安リソースの一つであります（というのは我がブログサイトのPV数が少ないからというのもあるんだけど）が、当時存在していたMicrosoft Standard版はまだまだ機能がそこまでしっかりしておらず、とりあえず

• 自前の証明書が使用できる
• ログはCore Analyticsぐらいしか拾えない
• 設定の柔軟性はあまりない

ということで、当時はどーしてもアクセスの見える化を優先していたこともあり、迷わずVERIZON Premiumを使用していたわけですが、ここ最近はいろんな機能が追加実装され、非常に運用しやすい代物になっており。

心惹かれたポイント

心惹かれたポイントは以下のところです。

• アクセスログがかなり詳細に拾えるようになった
• WAFと連携できるようになった

特にアクセスログが拾えるようになり、そんなに難しいことをしなくても十分にLogAnalyticsにデータを取り込むことができるのは非常に大きいわけでして。VERIZON Premiumではレポートの出力はできるのですが、ログそのものを取り込むというようなことはできなかったこともあり、この機能はどうしても使いたかった！というのがあります。

WAFとの連携も私としては衝撃でして、実は本日まで一生懸命Nginx向けのWAFであるNaxsiとにらめっこしていたのですが、どーーーーーーしてもホワイトリストの書式が完全に理解できず、どうしたらこのサイトにWAFをかけることができるようになるんだろうか・・・とちょっと参り気味ではありました。それが、Application GatewayやFrontDoorなどで使ってるようなWAFと連携させることができるというのは非常に衝撃でありました。

アクセスログの取得

アクセスログは「診断ログ」として収集することが可能で、CDNリソースを作った後に診断ログ設定を行うことにより取得できます。診断ログ設定で取り込まれるログなので、LogAnalytics上では「AzureDiagnotics」テーブル内に保存されます。

保存される内容は以下のような感じになります。結構細かく取れます。
レスポンスタイム、レスポンスコード、アクセス元などなど様々に情報が拾えますので、これだけでも十分ありがたいですね。VERIZON Premiumで作られてたレポートなども、LogAnalyticsとブックを活用することにより十分近いものが組めるのではないかと思います。

なお、「序盤苦戦していた」って何？と気づいた方もいるかもしれませんが、その件については後述します。

ルールエンジンは少々弱い

3年前に初めて使ったころと比べるとルールエンジンも強化され、VERIZON Premiumのように、ルールを順序付けて定義することが可能になりました。

が、Microsoft Standardのルールエンジンは少々アクションの選択肢が少なめです。

明示的にレスポンスコードを返すといったようなルールはどうやら書けないようで、例えばVERIZON Premium使ってた頃は管理画面に対して一切アクセスできないように403を返すように構成してたのがこのルールエンジンでは移植できませんでした。そこで、今回はトップページへ有無言わさずリダイレクトするよう構成しています。

WAFとの連携

Webアプリケーションファイアウォールですが、2017－2018年時点では、WAFが使えるリソースといえばApplication Gateway、FrontDoorの2種類でしたが、Azure CDNに対しても連携させることができるようになっています（実は知るのはだいぶ早かったんですが、金額的に厳しかったというのが正直なところです）

MicrosoftがOWASP3.ｘをベースにチューニングをしたルールエンジンが動いてるらしく、ルールの中身はApplication Gatewayのそれとは似て非なるものになっているんだそうで。

私はKUSANAGIでNginxを動かしていることもあり、本来はNaxsiというNginx向けWAFを使うことも可能だったのですが、どーしてもあの独特なログの読み方やルールの組み方にとっつけず、結構挫折感たっぷりな状態になっておりまして・・Orz

ゆえにMicrosoft Standardに乗り換えることができたこともあり、このWAFと連携させてみることにしています。こちらも「診断ログ」設定でWAFログをLogAnalyticsやストレージに飛ばすことができるようになっています。

リソース構成時、WAFはDetectionモード（検知のみ行うモード）になっているので、初期段階はそのまま検知のみ実行するように構成するのが良いかと思われます。

CDN Microsoft Standardでのハマりポイント

前述もしているんですが、実はこのCDNに乗り換える際、それなりに苦労しておりまして。というのが、CDNのプロファイルを作成、エンドポイントの設定をVERIZON Premiumと同様に実施してみたところ、以下のようなメッセージが出てブログサイトが表示できないじゃないかという。

Request cannot be served. 

で、当然検索エンジンとかでこのメッセージを調べたわけなんですが、なかなか有効な情報が見つからない。オリジンサーバのアクセスログを見ても全くアクセスした形跡が見られず、こりゃどうしたもんかなぁ・・と悩みまくりまして。

そこで改めて確認したのがLogAnalytics内に保管されたCDNAccessLog。すると、以下のような個所を確認したと。

どうやら5xx系のエラーが出た時、Azure CDNはErrorInfo_sというフィールドにその理由を記載するようで、その内容が「CertificateExpired」とのこと。はて？私のオリジンサーバの証明書がExpireしてる？そんな馬鹿な・・

とりあえず現在使用している証明書の期限を見てみると

# openssl x509 -noout -subject -issuer -dates -in www.bluecore.net.fullchain.2021.crt
subject=OU = Domain Control Validated, CN = www.bluecore.net
issuer=C = BE, O = GlobalSign nv-sa, CN = AlphaSSL CA - SHA256 - G2
notBefore=Jun 27 11:11:59 2019 GMT
notAfter=Aug 10 11:13:47 2021 GMT

上記の通り全く問題なさげです。今年の8月までKING SSLの証明書が有効に働いてます。
しかし、証明書の有効期限は過ぎているとおっしゃる・・と、ふと気づいたのが

Nginxのデフォルト設定で定義されているSSL証明書ってなんだっけ？

そこで調べてみるとどうやらビンゴ。KUSANAGI for Microsoft Azureでデフォルト設定に登録している証明書はなんと自己証明書でして。

# openssl x509 -noout -subject -issuer -dates -in /etc/pki/tls/certs/localhost.crt
subject=C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = kusanagi71, emailAddress = root@kusanagi71
issuer=C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = kusanagi71, emailAddress = root@kusanagi71
notBefore=Nov 18 12:08:26 2015 GMT
notAfter=Nov 17 12:08:26 2016 GMT

どうもMicrosoft Standardはこの証明書をどっかの処理過程で誤って参照し、結果として証明書期限切れでアクセスをやめてしまうということがわかりました。そこで、ブログ用の証明書を /etc/nginx/conf.d/_ssl.conf に対しても設定してアクセスしてみると、無事つながりました！という。

VERIZON Premiumでは発生しない現象なので、Microsoft系のCDNエンジンに何かしら癖があるのかもしれないです。

もしかしたら、以前Frontdoorでも似たような現象に悩まされていたんですが、実はこの対処をしたら治るかもしれませんね(;^_^A

総括

Microsoft StandardなCDNはVERIZON Premiumよりも安く、また、Microsoft直轄のリソースでもあることからかなりおすすめなのではないかなーと思います。何がうれしいって、OEMリソースではないこと。

OEMリソースの場合、Microsoftはあくまで「中継役」に過ぎず、VERIZON Digital Media Service宛に英語のメール文を書かなければならないというなかなかの苦行が待ってます(それでもMSサポートさんは可能な限り助けてくれるけど）。これがMicrosoft直轄のリソースとなると、Microsoftサポートへの問い合わせで対応が完結します。

そのうえで、「アクセスログが拾える」「WAFと連携できる」となると、十分これって費用対効果の高いサービスなんじゃないかなという気がします。まだWAFに関しては未知数ですが、ひとまずログを拾って分析しながら知見を拾い集めることができればなぁと思っています。