Windows Azure

Windows Azureにデプロイしたアプリに、特定のIPからのみ接続できるようにアクセス制限をする必要がある場合、Windowsファイヤーウォールの設定をプログラム的に変更することて対応できます。スタートアップ時と(Windows Azureゲストエージェントがファイヤーウォールの設定を戻してしまうので)ロールの変更時に設定する必要があります。

アクセス制限をしたい理由

Windows AzureにPaaSクラウドサースをデプロイすると、インターネット上にデプロイされます。
これは、インターネット上で誰でもアクセスできることを意味します(アプリケーションの認証ロジックがあるかもしれませんが)。
通常は、これは問題にはなりません。アプリを構築しデプロイすれば使用できるようになるからです。
しかし、特定マシンからのみ接続できるようにアクセス制限をしたいことがあります。

  • 未リリースで、準備が整うまでは非公開にしたいアプリケーション。
  • 複数の異なる環境のデプロイ(開発、テスト用など)があって、アプリケーションの認証ロジックを変更せずに許可された人だけがアクセスできるようにしたい
  • アプリケーションがインターナルユーザーのみ使用することを想定して設計されており、リモートから接続を許可したくない。この場合は、個別ユーザー認証のためアイデンティティソリューションを使用すべきです。
  • RDPや別のポートで運用している管理画面のような管理サービスに追加のセキュリティを施したい場合。

IISの「IPアドレスおよびドメインの制限」では不十分?

IIS干すテッドサービスへのトラフィックのみをブロックすることに興味がある場合、
IISの「IPアドレスおよびドメインの制限」機能が選択肢の一つになります
(詳細は、Liam CavanaghのBlog参照)。デフォルトではインストールされていないので、「IPアドレスおよびドメインの制限(IP and Domain Restrictions)」昨日をセットアップスクリプトをでインストールする必要があります。

この解決策では、RDPなどのIIS以外の接続も制限したい場合不十分です。

Windows Firewallでのアクセス制限

この場合、Windows Azure VMのローカルで動作しているWindows Firewallの設定を変更してあげる必要があります。通常、特定IPアドレスとポートからのみアクセスを許可するように設定するのは簡単です。

ここでは、Windows Server 2012、Windows Azure osFamilyの3で動作する、Netowork Security PowerShellコマンドレットを使用して、80と3389の2つのポートへの接続を特定IPからのみ許可する設定例を提示します。

# SetFirewallRestrictions.ps1
$date = Get-Date
Write-Host "Updating firewall rule restrictions at " $date "`r`n"
$allowedRanges = ('3.2.1.0/24', '1.2.3.4') 
Get-NetFirewallPortFilter | ? LocalPort -eq '80' | Get-NetFirewallRule | Set-NetFirewallRule -RemoteAddress $allowedRanges
Get-NetFirewallPortFilter | ? LocalPort -eq '3389' | Get-NetFirewallRule | Set-NetFirewallRule -RemoteAddress $allowedRanges

このスクリプトが呼び出されてたときログを出力するように.cmdファイルでラップします。

rem SetFirewallRestrictions.cmd
cd /d %~dp0
Powershell set-executionpolicy remotesigned -force
Powershell .\SetFirewallRestrictions.ps1 >> SetFirewallRestrictions.out.log 2>> SetFirewallRestrictions.err.log

スタートアップタスクで呼び出されるように、ServiceDefinition.csdefファイルを設定します。セキュリティ設定を昇格するように<Runtime>エレメントで設定します。

<ServiceDefinition name="FirewallTest" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2013-03.2.0">
  <WebRole name="WebRole1" vmsize="Small">
   ...  
    <Startup>
      <Task commandLine="Startup\SetFirewallRestrictions.cmd" executionContext="elevated" taskType="simple" />
    </Startup>
    <Runtime executionContext="elevated" />
  </WebRole>
</ServiceDefinition>

スタートアップタスクを設定すると、Windows Azureは自動的にファイヤーウォールの設定を更新し、IP制限を設定しインスタンスを起動します。ロースをスケールさせると、Windows Azure Gesut Agentは、Windows Firewallの設定を再作成します。IP制限を継続するには、ロールのトポロジーが変わった際に、スクリプトを再適用する必要があります。

アプリケーションがスケールしたときに、ファイヤーウォールルールを再適用するために、RoleEntryPointクラスで、RoleEnvironment.Changedイベントを使用します。

public class WebRole : RoleEntryPoint
{
    public override bool OnStart()
    {
        RoleEnvironment.Changed += RoleEnvironment_Changed;
        return base.OnStart();
    }

    void RoleEnvironment_Changed(object sender, RoleEnvironmentChangedEventArgs e)
    {
        if (e.Changes.Any(ch => ch is RoleEnvironmentTopologyChange))
        {
            var processStartInfo = new ProcessStartInfo(@"Startup\SetFirewallRestrictions.cmd");
            var process = Process.Start(processStartInfo);
        }
    }
}

元記事

MSDNブログ:Using Windows Firewall to restrict access to Windows Azure instances

Windows Azure

A6又はA7の仮想マシンサイズを使おうとしたときに、「Failed to configure virtual machine <machine name>.」や「Failed to create virtual machine <machine name>.」というエラーに遭遇するかもしれません。主に次の3つの場合に、エラーが発生します。

  1. A6やA7以外の既存の仮想マシンをサイズ変更してA6やA7にする
  2. 2013/4/16以前に作成した仮想ネットワークに新しいA6又はA7サイズの仮想マシンを作成する
  3. 既存のクラウドサービスに新しいA6又はA7サイズの仮想マシンを追加する

この問題に遭遇した場合には、シナリオケースごとに次の対応をする必要があります。

1. A6/A7に仮想マシンサイズを変更しようとすると失敗する

既存の仮想マシンを削除し、ディスクは維持します。既存のOSディスクか、オリジナルの仮想マシンディスクを使用して、新たにA6/A7サイズの加増マシンを作成します。

もしサイズ変更しようとしている仮想マシンと同じクラウドサービスに別の仮想マシンがデプロイされている場合、それらの仮想マシンも削除し、新しいクラウドサービスに再デプロイする必要があります。

2. A6/A7仮想マシンを既存の仮想ネットワークに追加しようとすると失敗する

新しい仮想ネットワークを作成し、その仮想ネットワークにA6/A7サイズの仮想マシンをデプロイします。

2013/4/15以降に作成された全ての仮想ネットワークは、全てのリージョンで高メモリの仮想マシンが提供された場合、A6/A7サイズの仮想マシンをサポートします。

3. 既存のクラウドサービスにA6/A7仮想マシンを追加する

既存のクラウドサービスを削除し、新たに作成したクラウドサービスにA6/A7をデプロイします。

一次ソース

MSDNフォーラム:「Error: “Failed to configure virtual machine” with new A6 or A7 size

Windows Azure

Windows Azure Virtual Machineで提供されているOpenlogicのCentOS 6.3イメージにはカーネルヘッダー(kernel-headers)が含まれていません。
その為、開発ツールをインストールしようとすると、インストールできずに途方にくれてしまいます。
開発ツールを入れないとソースからビルドして、ミドルウェアをインストールできないので、
結構いや~んな感じです。

そんな問題に対して、OpenLogic Azure Support Teamが、対応方法を回答していました。
(参考:Openlogic Centos 6.3 image: no kernel-headers

sudo yum –disableexcludes=main install kernel-headers-2.6.32-279.14.1.el6.openlogic.x86_64

カーネルヘッダーをインストールしなさいということですね。

ちなみに、自動スクリプトで対応したいなら、gccなどのパッケージをインストールする前に、次のようなコードを使えばいいよっとアドバイスしている人もいました。

sudo yum -y -q –disableexcludes=main install kernel-headers-*.el6.openlogic.x86_64

Windows Azure

AzCopyについては、MSエヴァの佐々木さんのBlog「azcopy – BLOB へファイルをやったり取ったり」や自分の過去の投稿「AzCopy–Windows Azure Blob用のファイルアップロード・ダウンロードツールがリリース」で紹介しています。

今回の投稿は、Windows Azure Storage Team Blogに投稿されたCTP2のリリースを知らせる「AzCopy – Using Cross Account Copy Blob」をざっくり意訳した投稿です。

AzCopy CTP2は、ここからダウンロードできます。参考用にAzCopy CTP1について説明したブログはここ(英語)です。

CTP2で追加された新機能

  • アカウント間のBlobのコピーをサポートしました。
    AzCopyは同一ストレージアカウント間、異なるストレージアカウント間のBlobコピーを可能にします(アカウント間のBlobコピーの詳細については、このBlog(英語)を参照してください)。アカウントから別のアカウントへBlobを移動する際のコストと時間を効率的にします。ストレージサービスがデータ転送を実施するので、あなたが転送元からBlobをダウンロードし、転送先にアップロードする必要はありません。
    /Z を使用して、再開可能モードで転送することができます。
  • /MOV を追加しました。
    このオプションは、コピー後、転送元から移動したファイルを削除します。
  • /NC を追加しました。
    ネットワーク並列度を指定することができます。デフォルトでは、ローカルコンピューターからWindows Azure Storageにファイルをアップロードするとき、AzCopyは並列タスクを実行するためにコンピューターがもっているコア数の8倍をネットワーク並列処理に使用します。たとえば、4コアのPCの場合、AzCopyは32個のネットワーク並列処理を実行します。CPUやネットワーク帯域使用量を制限したい場合は、/NCを使用して制限することができます。
    この値は、絶対値を指定するもので、コアごとの使用数を指定するものではありません。上の例で半分にしたい場合は、/NC:16 を指定します。
  • /SNAPSHOT を追加しました。
    スナップショットでBlobを転送できるようにします。
    AzCopy CTP1では、デフォルトでBlobのスナップショットを転送していました。今回のバージョンからは、Blobをコピーしている間、AzCopyはスナップショットを転送しません。
    /SNAPSHOTオプションを指定した場合のみ、AzCopyはBlobのスナップショットをすべて転送します。しかし、転送先ではオリジナルのBlobのスナップショットの代わりに複数のBlboに分かれています。転送されたBlobのスナップショットは次のような名前に変更されます。[blob名](スナップショット日時)[拡張子]。
    たとえば、転送しようとしたrename.txtファイルが3回スナップショットされていた場合、転送先では次のようなファイル名で格納されます。readme (2013-02-25 080757).txt / readme (2012-12-23 120657).txt / readme (2012-09-12 090521).txt
  • /@:response-file: を追加しました。
    ファイルにパラメーターを格納し、コマンドラインで指定した場合、AzCopyによって実行されます。パラメーターファイルは、1パラメーターにつき1行で記載し、複数行記載することができます。

使用例

異なるストレージアカウントへのコピー

AzCopy https://<sourceaccount>.blob.core.windows.net/<sourcecontainer>/ https://<destaccount>.blob.core.windows.net/<destcontainer>/  /sourcekey:<key> /destkey:<key> /S

スナップショットをコピーする場合

AzCopy https://<sourceaccount>.blob.core.windows.net/<sourcecontainer>/ https://<destaccount>.blob.core.windows.net/<destcontainer>/  /sourcekey:<key> /destkey:<key> /S /SNAPSHOT

コピー元からファイルを消したい場合

AzCopy https://<sourceaccount>.blob.core.windows.net/<sourcecontainer>/ https://<destaccount>.blob.core.windows.net/<destcontainer>/  /sourcekey:<key> /destkey:<key> /MOV /S

次のような応答ファイル「myAzCopy.txt」を作成し、実行する場合。

#URI of Source Container
https://<sourceaccount>.blob.core.windows.net/<sourcecontainer>/
#URI of Destination Container
https://<destaccount>.blob.core.windows.net/<destcontainer>/

AzCopy /@:C:\myAzCopy.txt /sourcekey:<key> /destkey:<key> /MOV /S

あああ

SQL Azure

今まで、Silverlight製の旧ポータルでしか操作できなかったSQL Reporting Services(SQLレポート)のサーバー管理がHTML5製の管理ポータルでできるようになりました(アナウンスはガスリーBlog)。

と言うわけで、早速操作してみました。

SQLレポートサーバーを作成する

左側のメニューに「SQLレポート」が追加されています。ぱちぱち。

image

ちなみに、左下の「+新規」、中央部の「レポートサーバーを作成する」のどちらをクリックしてもSQLレポートの作成画面は同じ画面が開きます。

image

今のところ、簡易作成以外の作成画面は用意されていないようです。まぁ必要性も薄いですが。

image

必要事項を入力して、「SQLレポートサービスの作成」をクリックすると、作成ステータスが表示され数分で完了します。

image

レポートサービス一覧のURLをクリックすると、SQLレポートのログイン画面が表示されます。

image

ログイン画面。ここでIDとPasswordを入れてログインすると・・・・・・・後は、今までと同じですね。

SNAGHTML163399d

SQLレポートサーバーのダッシュボード

SQLレポート一覧の左のほうをクリックするとダッシュボード画面が表示されます。

image

SQLレポートサーバーの使用状況を確認できます。

image

ユーザーの管理ができます。

image

レポートのアップロードやダウンロード、ディレクトリ作成などができます。

image