いろいろある Azure RemoteApp の活用シナリオ(第1回)

こんにちは、マイクロソフトの前島です。 モバイルワークや在宅勤務といった ”働き方の多様性を支える手段” として生まれた Azure RemoteApp ですが、それ以外の用途で活用いただくケースも増えています。お客様が実際にどのような使い方をされているのか、代表的なシナリオをご紹介していきます。 1. インターネット閲覧分離環境の提供 ここ最近、最もホットなシナリオがこちらです。 『標的型攻撃』によるリスクを緩和する手段として、社内ネットワークとインターネットの分離が有効であるとされています。たとえば、IPA が発行する『高度標的型攻撃』対策に向けたシステム設計ガイドでは、”対策セットD” としてネットワーク分離が推奨されています。 社内用とインターネット用で PC を2台用意するという方法もありますが、コストがかさみますし、利便性も相当損なわれてしまいます。Azure RemoteApp を利用して、インターネット閲覧専用環境(ブラウザ+PDFリーダー等の必要なアプリ)を提供することにより、論理的に社内環境との分離を実現できます。 上記イメージ図は、Azure RemoteApp を使ってインターネット分離を行っている状態です。一見、IE が2つ起動しているだけに見えますが、左側がローカルPC上で直接稼働するイントラネット用、右側が Azure RemoteApp 経由で提供されているインターネット用です。ユーザーはこれまでの操作性を損なうことなく、社内にもインターネットにもアクセスできます。 一方で、管理者はセキュリティを確保するために、ローカルPCへのデータ保管などを禁止することができます。(もちろんローカル保存を許可する設定もできますが、セキュリティを最重視する場合は無効化が推奨されます) 2. アプリケーション老朽化 (version up) 対応 PC上で稼働するアプリケーションの更改・バージョンアップは、IT管理者を悩ませる運用の一つでしょう。たとえば、Internet Explorer 11 へのマイグレーションに苦労された企業も多いかと思います。 もし新旧両方のバージョンを並行してユーザーに提供できれば、更改につきものの初期不具合リスクを軽減できますし、展開スケジュールの柔軟性が増します。 Azure RemoteApp 上で新バージョンのアプリケーションを先行提供することにより、ユーザーは新旧両方のアプリを同時に使うことができます。仮に新バージョン特有の問題が発生したとしても、PC上の安定バージョンを使って業務を継続できるわけです。 また、新バージョンが安定してきて、PC上のアプリケーション更改が無事に終わったユーザーについては、Azure RemoteApp のユーザー登録を解除すれば直ちに課金が停止するのも Azure ならではの特長です。 3. クライアントサーバー型システムの提供 クラウドが一般化する中、オンプレミスのデータセンターを縮小し、既存のシステム(サーバー)をそのままクラウドに持っていく、いわゆる “リフト&シフト” と呼ばれる使い方も少なくありません。 このとき Azure RemoteApp を併用し、クラサバ型システムにおける “クライアント部分” もクラウドに持っていってしまうというアプローチがあります。端末上にクライアントアプリケーションを残す場合に比べて、次のようなメリットがあります。…


Azure の仮想マシンとIPアドレス

インターネットでの通信を行うには、何らかの形で「IPアドレス」をネットワークインターフェイスの各ポートに割り当てる必要があります。発信元を示すのに自身のIPアドレスを、宛先を示すのに相手のIPアドレスがパケットのIPヘッダに記載されます。複雑に絡み合うインターネットなかを、宛先のIPアドレスを頼りにパケットは相手に送り届けられ、そして相手は発信元IPアドレスへ返信を行うわけです。 さて、Azure の仮想マシンの場合、1つのネットワークインターフェイス(NIC)に対して「パブリックIPアドレス」と「プライベートIPアドレス」の2つの設定があります。  (ネットワークインターフェイスのIPアドレスの設定: パブリックとプライベート、2つのIPアドレスの設定がある) ● プライベートIPアドレス 仮想マシンのNICに実際に割り当てられるのは「プライベートIPアドレス」です。VNETに設定されたサブネットから選ばれたIPアドレスがDHCPで割り当てられます。NICに対して特定のIPアドレスをゲストOS側で設定するのではなく、必ずDHCPで割り振ることから、DIP(Dynamic IP)とも呼ばれます。なお、「プライベートIPアドレス」とありますが、192.168.x.x 等のいわゆる(RFC1918で定められた)IPアドレスレンジである必要はありません。任意のアドレスレンジを設定することができます。もちろん、インターネットで誰かが使っているレンジを使用するとそ事の通信で齟齬を起こしますので、特に理由がない限りはいわゆるプライベートIPアドレスのレンジから割り当てる方が無難です。  「動的」の「プライベートIPアドレス」の場合、仮想マシンの起動すると、NICに対してサブネットから空いてる適当なIPアドレスがDHCPによって割り当てられ、仮想マシンが停止されると解放されます。次回起動時に同じIPアドレスが割り当てられる保証はありません。一方、「静的」の場合は、DHCPを通じてIPアドレスが割り当てられるのは同じですが、設定したIPアドレスが必ずそのNICに割り当てられます。  デフォルトは「動的」になっており、また通常は動的で問題ありません。ただし、内部的なDNSサーバを立ち上げたり、ActiveDirectory のドメインコントローラを立ち上げるなど、IPアドレスが変わると困ってしまうサービスを使用する場合は「静的」にします。 この「プライベートIPアドレス」で通信できる範囲は以下の通りです  同じVNETに所属する仮想マシンやサービスとの間 S2S VPN で接続されたネットワーク VNET-to-VNET VPNで接続された相互のVNETに属する仮想マシン、サービス P2S VPN で接続された端末 ExpressRoute で接続されたオンプレミスのネットワーク 同じ ExpressRoute に接続した VNET の間 インターネットへはこの「プライベートIPアドレス」では直接通信できません。インターネットからの通信を受け付ける場合には、次の「パブリックIPアドレス」が必要になります。  ● パブリックIPアドレス 「パブリックIPアドレス」はインターネットからの通信を受け付けるのに必要なアドレスになります。この「パブリックIPアドレス」は仮想マシンのNICには直接は割り当れません。 外部からそのIPアドレスへパケットを送ると、Azure でNATがかけられ「プライベートIPアドレス」に書き換え(マップ)された上で、仮想マシンのNICに到着します。仮想マシンから送付した場合は逆に「プライベートIPアドレス」から「パブリックIPアドレス」に書き換え(マップ)されます。NICには直接設定されてないけど、実質的に使用されている事から、「VIP」(Virtual IP)とも呼ばれます。 (プライベートIPアドレスはNICに割り当てられ、パブリックIPアドレスはインターネットとのアクセスでマップされる)  「パブリックIPアドレス」にもまた「動的」と「静的」があります。 「動的」は仮想マシンが起動したときにIPアドレスが割り当てられ、停止したときに解放されます。「静的」は特定のIPアドレスが常に割り当てられます。なお、静的に確保された「パブリックIPアドレス」は「予約済IPアドレス」とも呼ばれます。  「パブリックIPアドレス」には「プライベートIPアドレス」の時と異なる点がいくつかあります。VIPとしてマップ(NAT)されるというのもその1つです。それ以外にも、以下の点が異なります。 ● パブリックIPアドレスには「DNS名」が付けれる 「パブリックIPアドレス」は、<指定の名前>.<ロケーション>.cloudapp.azure.com というDNS名を設定することができます。例えば、東日本リージョンで動作している foocontoso という名前の仮想マシンなら、foocontoso.japaneast.cloudapp.azure.com というDNS名を付けれます。 インターネット側の端末などからは、IPアドレスの値だけではなく、foocontoso.japaneast.cloudapp.azure.com という名前でもアクセスを行う事ができる訳です。  これは特に、「動的」の「パブリックIPアドレス」の場合に便利です。動的のIPアドレスは仮想マシンの停止~起動で IPアドレスの値が変わりえます。IPアドレスを指定してのアクセスだと、毎回IPアドレスを確認する必要が出てきます。IPアドレスが変わってもこのDNS名とIPアドレスの対応は追従しますので、DNS名ならば IPアドレスの変化を気にする必要がなくなります。 お客様側のDNSの設定を追加することで、<名前>.<ロケーション>.cloudapp.azure.com ではないDNS名を使う事も可能です。例えば…

0