毎年恒例アドベントカレンダーですが、ちょっとマイナー系（？）なContribution License Agreement （CLA）まわりを書こうと思ったらまさかのネタ被りしたので違うこと書きます（未着手だったので問題はない）
というわけで、この記事はAzure Advent Calendar 2014 の10日目の記事です。ちなみに過去こんな感じでやってます。
なんかその年の潮流というか雰囲気がわかって見返しても楽しいですね。（しかし時の流れは無情だな）
さてさて、今年はAzure Websitesにひっそりと追加されている認証/承認機能（Preview）を試してみたいと思います。公式的にはこちらを参照ください。
元ネタ：Azure Virtual Network Gateway Improvements
TechEd Europe 2014で仮想ネットワークゲートウェイの改善が発表されました。
これまでのゲートウェイとの違いは以下の表のような感じです（これまでがDefault）
| SKU | ExpressRouteスループット | S2S VPNスループット | S2S最大トンネル数 |
| Default | ～ 500 Mbps | ～ 80 Mbps | 10 |
| High Performance | ～ 1000 Mbps | ～ 200 Mbps | 30 |
ちなみにお値段も少し違います。（1時間あたり0.49ドル） データ転送料などは同じ。
制限としては静的ルーティングゲートウェイは未サポートで、動的ルーティングゲートウェイとExpressRouteのときだけ使えます。
新規に作ることもできるし、既存のゲートウェイを変更することも可能です。
新規の時はNew-AzureVNetGatewayコマンドレット（Azure PowerShell）等で –GatewaySKU に指定するだけです。
New-AzureVNetGateway -VNetName MyAzureVNet -GatewayType DynamicRouting -GatewaySKU HighPerformance
HighPerformance か Default を指定します。
Resize-AzureVNetGateway コマンドレットで変更します。
Resize-AzureVNetGateway -VNetName MyAzureVNet -GatewaySKU HighPerformance
ゲートウェイの作成や削除、ExpressRouteのサーキット作成・削除・サーキットリンクの認証や作成・削除・BGPセッションの作成・削除・アップデートなどが管理ポータルの操作ログに出力されます。
PFSはややこしいけど秘密鍵と公開鍵などが漏れてもセッションの機密は保たれる（セッションキーを別で生成するので安全）みたいな鍵交換の方式です。
で、この方式をサポートするので対応する機器であればより安全なセッションを張ることができるでしょうたぶん。
※IPSec（と他一部プロトコル）ぐらいしかサポートしてないので、S2S (VNET to VNET)のみサポートです
S2Sの接続をする際に、暗号化せずに接続することができるようになりました。一般的にAzure上のVNET同士を接続する場合は比較的安全（盗聴される可能性が一般的なインターネット経由よりかなり低いという意味）なので、パケットの暗号化をしないことでスループットを上げることが可能です。
※On-Premiseとの接続などの場合はやめましょう
17日にアナウンスがありましたが、Azureの仮想ネットワークで設定できるアドレス空間がRFC1918に記載されているプライベート空間以外も指定できるようになりました。
ようは以下の3つのアドレス空間内でやりくりしてねってのが今までです。
今後は関係なく設定できるようになったので、より柔軟にネットワークが構成できるかもですね。（IPアドレスは正しく使いましょう）
TechEd Europe 2014のKeyNoteがあるからかわかりませんが、いろいろUpdateがありました。公式Blogはまだなので適当に公式ドキュメントなどからPick Up。TechEdの情報もあれば随時Updateしていきます。
※ScottGuが公式出してきたので追記しました。
そんなわけでAzureConfの季節がやってまいりました。
Scott Guthrieはじめ著名な人たちがAzureの最新事情についていろいろ教えてくれるConferenceです。公式サイトを追ってもいいですし、Twitterでの質問も受け付けたりしてるので #azureconf ハッシュタグを追いかけるのもいいかともいます。
で、今年は4年前のPDC10みたいな感じでパブリックビューイングしよう！というノリと勢いのイベントも一緒にやってみました。
ただの居酒屋トークになった感はひしひしと感じてしまいますが、なんとなくわいわい見れるといいなーという感じでUSTREAMで配信してみました。（ユニーク視聴者数で170名ぐらい見て頂いたようです。夜中にお疲れ様でした）
少し前から既にPreviewとれていましたが、WebJobsがGAしました。
WebJobs SDKは1.0が今RCですね。結構勢いがある機能じゃないでしょうか。
リソースはこちらにまとまっているので参考に。
しばやん先生も記事にしていました。
ちなみにしばらく見ない間にジョブの詳細みたりログみたりもかなりよくなってますね。
※ログビューアーはSite Extensionsですね
いろいろありましたがDavid Ebbo先生がAzure WebサイトでSSL 3.0をオフにする方法を用意してくれました。（正確にはオフではなく拒否ですが）
やりかたは2パターンあります。とりあえずSSL 3.0が有効な状態を見ときましょう。（curlでやるとクールだけどIEでとりあえず。）
TLSがOnだとそっち使っちゃうので一時的に。で、Azure Webサイトにつないで見ます。
こんな感じでSSL 3.0です。サイトは普通に見えます
KuduにアクセスしてSite ExtensionsでDisable SSLv3をインストールします。
プレビューポータルだともう少し簡単です。（わざわざKuduにつながなくても良い）
簡単です。プレビューポータルだと再起動もされるので簡単ですね。ではブラウザでつないで見ましょう。
403になりました。TLS有効にするとちゃんと見えます。
※ちなみにこのExtension有効にすると、Extension消しても403になっちゃう気がします。。
もう1つの方法として提示されたのがURLRewriteを使う方法です。Azure Webサイトのフロントエンドのロードバランサーが、クライアントがSSL 3.0を要求してきたときに X-Forwarded-SSLv30 という特別なリクエストヘッダを付与してくれるので、こちらを見て判断する方法です。
（TLSで接続している場合などはこのリクエストヘッダが付与されません）
以下のようなルールをWeb.configに追記します。
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Block SSL3.0" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" />
<conditions>
<add input="{HTTP_X_FORWARDED_SSL30}" pattern="1" />
</conditions>
<action type="CustomResponse" statusCode="403" subStatusCode="900" statusReason="Forbidden" statusDescription="SSLv3 connections are forbidden by this site" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
こんな感じになります。
Web.configだけで設定のOn/Offできるので、こちらのほうが使い勝手がいいかもです。（但しステータスコードが例だと403になるだけなので注意 ※CustomErrorsとか設定してないとという話）
クラウドサービスや仮想マシンについては以前書いた通りです。
SSL 3.0が完全に使われてない技術であればWebサイトもホスト側ですぱっとオフにできるのでしょうけど、そうじゃないクライアントがあるのでサービス側としてはこのような形でエラーにさせる方向なのでしょうね。
完全にクライアントの問題とも言えませんがクライアント側で少なくともSSL3.0使わなければ良いはずですので、サーバー側でどうするかは状況によりけりということでしょうか。（少なくとも現状は）
あ、ちなみにモバイルサービスもKudu使えるはずなので、同じ手段で対策できるかと思います。
URLRewriteでSSL3.0接続のときに403を返しつつカスタムエラーでユーザーにSSL3.0の無効化を促すようにする場合はこんな感じにすると良さそうです。
カスタムエラー用のCSHTML
@{
Response.StatusCode = 403;
}
<!DOCTYPE html>
<html>
<body>
<h1>SSL 3.0を無効にしてTLSを有効にしてください</h1>
</body>
</html>
Web.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="webpages:Enabled" value="true" />
</appSettings>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
<httpErrors errorMode="Custom">
<remove statusCode="403" />
<error statusCode="403" path="/403.cshtml" responseMode="ExecuteURL" />
</httpErrors>
<rewrite>
<rules>
<rule name="TestBlock" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" />
<conditions>
<add input="{HTTP_X_FORWARDED_SSL30}" pattern="1" />
</conditions>
<action type="CustomResponse" statusCode="403" subStatusCode="900" statusReason="Forbidden" statusDescription="SSLv3 connections are forbidden by this site" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
結果
静的ファイルだとステータスコードが200に上書きされるようなので、CSHTMLで強制的に403を返すようにするようです。
たけぱらさんありがとうございます。
これでSSL3.0の時はエラー扱いにして且つユーザーに注意を促すことができますね。
※ ただ結局SSL3.0で繋いじゃってるので脆弱な状態といえば脆弱です。注意しましょう。まぁ注意を促したりするための対応なのでクライアント側で気を付けましょうね。ということです。
なんかScottGuのBlog見てたら補足できてなかったのがちらほらと。
適当に羅列しておきます。
そんな感じで今日もAzureは表に出ないところもUpdateされてました。
ちょっと前にAzure用Microsoft AntimalwareがGAしました。ので今日はその辺さらっと見ておきます。
Microsoft Antimalwareはそのまんま名前の通りOSをウィルスだったり不正なアプリから保護してくれるアプリです。Azure対応ということで、クラウドサービスと仮想マシンで使うことができます。
詳細はこちらのホワイトペーパーをどうぞ（直リン） → Microsoft Antimalware white paper
GA当初（10月3日）、ホワイトペーパーをざっとみてクラウドサービスの場合はSDK使うのかなー（と図を見て）と思ったのですがそんなことはなかったです。結局、クラウドサービスも仮想マシンもAzure PowerShellを使って構成する感じでした。
いろいろきました。例によって適当にピックアップしておきます。
というわけで今日のアップデートでした。
ブチザッキ 