Azure App Service / Web Apps、ウェブサイトへのアクセスを制限する[その2]

Azure App Service / Web Apps、ウェブサイトへのアクセスを制限する[その1] では、IPアドレス帯で、アクセス制限する方法を説明しました。 [その2]では、Azure AD でのIDプロバイダー認証&認可を説明します。 その前に「認証」と「認可」の違いをしっかり理解してておくことが大事です。英語だと、Authentication、Authorization です。英語でも日本語でも似たような単語なので混同されている場合もよくあるので、このふたつの定義の理解は重要です。(Azure ポータルでは「認可」ではなく、「承認」となっています。) Azure AD を使った認証&認可でのアクセス制限では、認証には、Azure AD を利用し、認可は、特定のAzure AD に所属しているユーザーにアクセス権を与えるのがもっともシンプルです。 実際の設定方法については、「Azure Active Directory ログインを使用するように App Service アプリケーションを構成する方法」を参照してみてください。この認証&認可の設定で、指定したAzure ADに登録されているユーザーのみ、そのウェブサイトにアクセスできるようになります。ステージングウェブサイトであれば、事前にウェブサイトをチェックするべきユーザーにAzure ADのアカウントを発行すれば良い事になります。 [その1]で紹介した、IPアドレス帯での制限と比較すると、AzureADを利用する方法は、アクセス元のIPアドレスを制限しないという点で柔軟です。たとえば、外出先からステージングウェブサイト上のコンテンツを確認したい場合など、IPアドレス帯で制限していると、VPN経由でアクセスするなどの手段が必要となりますが`、Azure ADを使う方法の場合、公衆端末からもアクセスできます(ブラウザはプライベートモードを使うなど気を使う必要はあります)。 なお、Azure AD についても最小限の知識は必要になります。特に Azure AD の組織アカウント(独自ドメインを適用していなければ、****.onmicrosoft.com という形式になります)と、Microsoft アカウント(***@live.com、***@hotmail.com、***@outlook.comなどのメールアドレスが使われることが多いです)は、どちらもマイクロソフトのIDプロバイダーですので、混同されてるケースもあります。この違いは、ぜひ理解していただきたいので「Azure Active Directory のドキュメント」から始まるドキュメントは目を通しておくことをお勧めします。 尚、Google、Facebook、Twitter、マイクロソフトIDを使用した認証もApp Service / Web Apps は対応していますが、認可については、ウェブアプリケーション側で実装が必要になるので、Azure AD認証のように設定だけでアクセス制限することはできません。

0

Azure File Storage への同一リージョン以外からのアクセスは SMB 3.0 が必須

Azure File Storage は、SMB プロトコルでマウントできるストレージです。SMB のバージョンは、2.1と3.0がサポートされていますが、SMB 2.1 の場合は、Storage アカウントの存在するデータセンターにデプロイされた仮想マシンからのみアクセスが可能です。 他のリージョンにデプロイした仮想マシンやオンプレミスのコンピューターからは、SMB 2.1 ではマウントできません。具体的には、以下の Windows に影響があります。 Windows Vista Windows 7 Windows Server 2008 (R2を含む) 詳細については、「Windows で Azure File Storage を使用する」 をチェックしてみてください。

0

Azure App Service / Web Apps、ウェブサイトへのアクセスを制限する[その1]

App Service / Web Apps を使ってウェブサイトを構築する際、様々な場面で、特定ユーザーのみアクセスを許可したい場面、いわゆるアクセス制限をかけたいという場面があります。 例えば、公開前の作業サイト、いわゆるステージングサーバー。社内からのアクセスのみ許可したいといったイントラネットの拡張サイト。などなど色々なシナリオがあります。 App Service / Web Apps では、フロントエンドのロードバランサーを他のユーザーと共有しているため、必ず、インターネットへ公開する、という仕様のために、上記のような制限を実施したいというニーズがうまれます。 App Service / Web Apps で、ウェブサイトへのアクセスを制限するには以下の方法があります。 アクセス元のIPアドレス帯での制限する Azure Active Directory(Azure AD) での ID プロバイダー 認証&認可 (基本認証・ダイジェスト認証) 基本認証・ダイジェスト認証は、App Service / Web Apps の機能としては提供されていませんので、1. もしくは 2. の方法を考慮します。(ただし、基本認証・ダイジェスト認証が、App Service / Web Apps で利用できないわけではありません。追って紹介したいと思います。) それぞれ特徴がありますが、公衆回線利用の場合など、アクセス元が固定されていない場合は、Azure AD 認証を利用。IPアドレスが固定されているオフィスからのみアクセスであれば、IPアドレス帯での制限が利用しやすいと思います。 アクセス元のIPアドレス帯で制限する この方法は、IIS の設定で実現します。App Service / Web Apps の機能ではありませんが、実際に、IPアドレス帯でアクセス制限が可能です。 具体的には、web.config…

0

Windows 10 on Azure の現状について as of 2017.04

こんにちは、マイクロソフトの前島です。 前回投稿からだいぶ日が空いてしまいましたが、XenDesktop Essentials および XenApp Essentials の提供が先月開始されるなど、これまで “Citrix on Azure” としてお伝えしてきた情報が形になってきています。 早速、XenDesktop Essentials や Citrix Cloud を使って Windows 10 を展開いただくケースも多く出てきていますが、ライセンス体系等の情報が錯綜していますので、ここで整理させていただきます。


Citrix on Azure 最新情報 as of 2017.01

こんにちは、マイクロソフトの前島です。  先週 Citrix Summit 2017 というイベントが開催され、VDI on Azure を実現する XenDesktop Essentials などの情報が出てきました。前回記事から日が空いてしまいましたが、現時点での最新情報をまとめてご紹介します。 ■ 要約すると… 昨年5月の Citrix Synergy でも発表された通り、Citrix と Microsoft は戦略的提携関係のさらなる拡大と強化を図ります。 Citrix on Azure として、2つのクライアント仮想化サービス(DaaS: Desktop-as-a-Service)が登場します。 Azure RemoteApp の後継として開発が進められてきた XenApp “Essentials” は、XenApp Essentials と名称を改め、今年3月末をターゲットに開発が進められています。 Windows 10 VDI on Azure を実現するサービス XenDesktop Essentials は、2月末~3月を目標に開発が進んでいます。 XenApp Essentials と XenDesktop Essentials の具体的な価格発表はまだ行われていません。 他分野での協業も進んでおり、本サミットでは XenMobile Essentials for EMS や…


XenApp “express” (Azure RemoteApp 後継) に関する最新情報 as of 2016.08

こんにちは、マイクロソフトの前島です。 本日、Citrix / Microsoft 共催のバーチャルイベントが開催されました。前回記事でお伝えした情報からの差分を中心に、大まかにまとめてみます。 (オンデマンド版もご視聴いただけるようになっていますので、ご興味のある方はできる限り直接ご視聴いただくことをお勧めします)   ■ 5行でサマリーすると… Citrix と Microsoft が “Comprehensive Partnership (包括的な提携)” を行っていくことが改めて発表されました XenApp “express” は Azure RemoteApp の後継として、Azure Marketplace 経由で提供されます クラウド上で VDI サービスを提供する XenDesktop – Windows 10 service on Azure も登場します 他の協業施策の具体例として、Windows Server 2016 の Day 1 サポートや、Azure AD 経由で Citrix Receiver を使ったシングルサインオン・シナリオが紹介されました 価格体系やサポート体制等の情報公開、実環境を使ったデモ等は行われませんでした。9月末の Ignite で、初のデモを予定していることが伝えられました。


Azure RemoteApp 提供終了と今後に関する補足

こんにちは、マイクロソフトの前島です。 8月12日(日本時間では8月13日未明)、Microsoft のデスクトップ仮想化ソリューションに関する重要な発表がありました。この中には、既存サービスである Azure RemoteApp (以下 ARA)提供終了のお知らせも含まれています。   “サービス提供終了” という言葉だけだと、どうしてもネガティブな印象を持たれる方もいらっしゃるかと思います。 ですが今回の施策は極めて前向きなものであり、現在 ARA をご利用中のお客様を含め、すべてのユーザーによってプラスとなるように検討した結果であるとご理解ください。   公式発表記事(英語)だけではご理解しにくい点もあるかと思いますので、現時点でお伝えできる情報を整理してご紹介します。


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

こんにちは、マイクロソフトの前島です。 少し間が空いてしまいましたが、今回も Azure RemoteApp の代表的な使い方を3つご紹介していきます。(第1回は こちら) 4. モバイルワーク・在宅ワークの実現 5. 海外からの社内システムアクセス改善 6. ソフトウェアの SaaS 化


いろいろある 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