Azure の詳細

[アーティクル]
02/06/2015

BYOD の課題: モバイルデバイスを企業に接続する

Bruno Terkaly 企業環境での私物デバイスの業務利用 (BYOD: Bring Your Own Device) を取り巻く動向にはまだ多くの懸念がありますが、Microsoft Azure Mobile Services は開発者にとってどのように役立つでしょうか。Microsoft Azure Mobile Services の核となる価値は、ID を民主化し、保護された企業リソースへの安全なアクセスを提供するコストと作業を軽減することです。今月は、モバイルアプリを使って企業リソースに接続する際の複雑なシナリオをサポートするために必要なことを詳しく見ていきます。

まず、ID の関係者を定義します。社員、取引パートナー、顧客それぞれの類似点と相違点を確認します。次に、オンプレミスのサービスとサイトにアクセスするブラウザーやモバイルデバイスユーザーが安全に接続できるソフトウェアアーキテクチャについて調べます。最後に、Microsoft Azure Mobile Services のバックエンドやオンプレミスのサービスエンドポイントに接続する iOS アプリを使用して、こここで説明する手法のデモを行います。

アクセスはすべて同じとは限らない

今回の取り組みには重要な目標がいくつかあります。最初の目標は、カスタムコードやインフラストラクチャ (既存のネットワーク構成など) への変更を最小限に抑えて、オンプレミスのリソースにアクセスできるようにすることです。もう 1 つの目標は、このような使用シナリオを管理して、アジャイル性や柔軟性を残しつつ、操作性と視認性を確保することです。

企業ファイアウォールの背後にアクセスする必要があるユーザーをすべて同じように作成するわけではありません。また、企業ファイアウォールの背後にあるすべてのデータに同じ保護レベルを設定する必要もありません。社員によっては保護された情報への適切なアクセスが必要になる場合もあります。たとえば、店舗の販売員は、製品価格や在庫量についての最新情報にアクセスする必要があります。場合によっては、口座の最近の支払い状況など、顧客の会計データにアクセスすることも必要です。しかし、人事アプリケーションにアクセスする必要はないでしょう。

取引パートナーには、独特のニーズがあります。信頼関係のあるビジネスパートナーは、エクストラネット経由で ID のフェデレーションを行うことがしばしばあります。取引パートナーは、一般に独自の ID インフラストラクチャを管理してユーザーを認証し、"要求" を使用して企業の保護されたリソースへのアクセスを調整します。そのため、パートナーまたは企業のいずれかが信頼ポリシーを使用して、保護されたリソース (社内 Web アプリケーションなど) が理解できる要求に受信要求をマップすることになります。

あまり知られていない ID 関係者が他にも 2 種類あります。PayPal や Netflix のようなアカウント情報へのアクセスを必要とする顧客が多くいます。見込み顧客も事実上顧客と考えられます。見込み顧客とは、クレジットカード情報を登録したけれども、実際にはまだ何も購入していない顧客です。こうしたさまざまな種類のユーザーがすべて、iOS デバイス、Android デバイス、Windows Phone デバイスを会社に持ち込んで仕事に使いたいと考えています。

企業のセキュリティ管理

企業でモバイルデバイスをセキュリティ保護する場合、少なくとも 5 つのソフトウェアスタックが関係します。ここでは、そのうちハイブリッド接続、Microsoft Azure Service Bus、Microsoft Azure Active Directory アプリケーションプロキシ、および Microsoft Azure API Management について詳しくみていきます。

社員が Web UI を使って Microsoft Azure Active Directory に自身の資格情報を提示し、アクセストークンを受け取り作業を始めるという考え方が簡単ですが、ID を取り巻く環境には微妙な差異があり、複雑です。簡単に言えば、「すべてに当てはまる 1 つの考え方」というのはありません。社員は通常、自社の ID プロバイダーを使用しなければなりません。

大半の企業は、一般に Active Directory を採用して ID を社内で利用できるようにし、多くの場合 LDAP ベースのプロトコルを公開します。クラウドに対応する新しいモバイル環境の場合、モバイルデバイス向けに HTTP ベースの通信プロトコルが必要になります。マイクロソフトは、この種の ID システムを Azure で作成しています。それが Microsoft Azure Active Directory (以下 Azure AD) です。Azure AD の優れた機能の 1 つは、企業がディレクトリ同期を使用して ID をクラウドと同期できることです。このプロセスの詳細については、https://technet.microsoft.com/ja-jp/library/hh967642.aspx を参照してください。

Azure AD には他にも優れた機能があります。Azure AD では、シングルサインオン (SSO) の利便性が提供されます。これにより、社員はログインや資格情報を何度も入力することなく、保護されたリソースにアクセスできるようになります。アクセストークンは社員のデバイスに Cookie としてローカルに保存されます。トークンの有効期限を利用すれば、アクセスを制限できます。

Azure AD では、認証におそらく最も広く採用されているオープンスタンダードの OAuth 2.0 もサポートします。これは、サーバーリソースへのセキュアなアクセスをリソースの所有者に代わって委任し、クライアントアプリケーションに提供します。Azure AD は OAuth 2.0 を使用してユーザーを認証し、SAML 2.0 トークンまたは JWT トークンのいずれかを発行します。トークンのしくみについては、bit.ly/1pDc0rg (英語) を参照してください。

取引パートナー

これまで企業はフェデレーションの信頼関係を利用して各企業の IT インフラストラクチャどうしの相互認証を管理していました。これには、2 つの企業のフェデレーションサービス間で信頼関係を確立する必要があります (図 1 参照)。これまでどおりの方法でも、ビジネスパートナーとの Web ベースのセキュアな取引がサポートされますが、言葉通りには簡単ではなく、実際には課題が存在します。

図 1 Active Directory フェデレーション向けのこれまでの ID モデル

パートナーは、自社の Active Directory と相手先企業の Active Directory との間に信頼関係を確立する必要があります。これにより、社員は自社の Active Directory で認証を行い、その認証トークンを相手先企業の Active Directory と交換して、相手先企業のネットワークにあるアプリにアクセスできるようになります。このアプローチでは、IT 管理者が多くの調整作業や手作業のワークフローを実行する必要があります。

図 2 は、これよりも新しい ID 管理のアプローチを示しています。一般に、社員の ID のコピーは Azure でホストされます。ただし、ID によっては Azure だけでしか管理されないものもあります。ほとんどの ID のオリジナルのコピーは社内で管理されるため、メンテナンスは最小限に抑えられます。バックグラウンドの同期プロセスにより、クラウドに置かれた ID のコピーは完全に同期されます。ユーザーは、クラウドのデータセンターにある Azure AD に直接接続でき、適切なアプリケーションにリダイレクトされます。

図 2 ID 管理の新しいアプローチ

モバイルアプリの開発者向けに、GitHub には Azure AD を活用できる多くのライブラリがあります (bit.ly/1qmeipz、英語参照)。

Android、iOS、Microsoft .NET Framework、JavaScript、Node.js などがすべてサポートされます。たとえば、iOS のサンプルでは、対話型認証コードを取得して、職場のアカウントと連携させる方法が示されています。この職場アカウントをデータセンターで実行中の Active Directory サーバーに結び付けるか、Azure AD を使ってクラウド内でそのまま利用できます。バックエンドでは、REST ベースの Node.js API または .NET Web API のいずれかが使用されます。

顧客のアクセス

通常、顧客が利用するサイトやサービスから、社内の保護されたリソースにアクセスできるようにしようとは思いません。ただし、考える以上にこのようなアクセスが必要になる場面はたくさんあります。たとえば、Wells Fargo は、セキュアな Web サイトやモバイルアプリを使って顧客の財務データを Web 経由で公開することを求めることがあります。Netflix は、現在の口座残高や支払履歴などの保護されたリソースへのセキュアなアクセスを提供するよう求めることがあります。このようなことは、モバイルデバイスを利用する顧客にとって特に重要です。

シナリオによっては、Microsoft アカウント、Facebook、Google、Twitter などのソーシャル ID プロバイダーを利用できる場合もあります。このアプローチについては、12 月号の「Azure の詳細」(msdn.microsoft.com/magazine/dn818496) コラムでデモしました。このコラムでは、ID プロバイダーとして Twitter を使用するネイティブな iOS アプリを作成しました。

このアプリでは、だれでもアプリをダウンロードでき、Web サイトにアクセスできることを想定しています。だれでも利用できるサービス層を用意します。通常、見込み顧客には、認証を受けなくても利用できるエクスペリエンスを用意し、公開可能な情報だけを表示します。このようなケースでも、社内リソースへのアクセスが必要になることがあり、サービスでは、認証を受けなくてもアクセスできる層をサービスに用意したり、一連の既定の資格情報に応答することになります。

セキュアな接続ツール

ID の話はこれぐらいにし、企業のネットワークのリソースにユーザが安全に接続できるようにするツールについて考えます。このようなツールはいくつかあります。たとえば、Microsoft Azure Service Bus Relay (図 3 参照) は、保護されたリソースに簡単にアクセスできるようにする優れた方法を提供します。Microsoft Azure Service Bus Relay は、クラウドでホストされるサービスで、クライアントと社内リソースを仲介するゲートキーパーとして機能すると考えて差し支えありません。Service Bus Relay は認証を受け、送信ポートだけを開きます。トピックとキューをサポートし、分散メッセージングの形式で実装することもできます。大量のイベントを利用する必要がある場合は、Event Hubs を組み込むこともできます。

図 3 Microsoft Azure Service Bus Relay

このアプローチのメリットは、社内ネットワークの構成を変更する必要がないことです。クライアントとバックエンドサービスはどちらもート 80 または 443 への送信接続を使用するため、ユーザーのプロビジョニングを行ったり、ファイアウォールの設定を変更するなどの構成変更は必要ありません。つまり、受信トラフィックに対して追加のポートを開く必要がなく、プロキシも必要ありません。

アプリケーションプロキシアプローチ

ファイアウォール外から保護されたリソースにアクセスできるもう 1 つのアプローチに、現在プレビュー版の Microsoft Azure AD アプリケーションプロキシサービスを使用する方法があります。このサービスは、社内の Web アプリやサービスに HTTP や HTTPS Web プロトコルを使って安全にアクセスできるようにします。

このアプローチの最大のメリットは、ユーザーはドメインに参加していない管理対象外のデバイスをそのまま使って、SSO やネイティブアプリのエクスペリエンスを利用できる点です。以前、デバイスを完全にドメインに参加させるよりも柔軟な「社内参加」の考え方について説明しました (https://msdn.microsoft.com/ja-jp/magazine/dn818496.aspx 参照)。このアプローチでは、ユーザーが個人所有のデバイスの制御権を手放さない BYOD のシナリオをサポートします。

Azure AD アプリケーションプロキシは、Azure AD との密接な統合、SSO、SaaS、オンプレミスアプリのサポート、多要素認証、デバイスの登録をサポートします。コネクターが、リソースとアプリケーションプロキシ、ひいてはモバイルアプリとの橋渡しを行います。コネクターは、基本的にはトラフィックをルーティングし、冗長性、スケーラビリティ、複数サイトをサポートします。

アプリケーションプロキシのメリットはいくつかあります。まず、アプリレベル、デバイスレベル、ユーザーレベル、および場所レベルで細かい制御を実装できるようにします。既存のクライアントアプリを変更する必要はなく、デバイス自体を変更する必要もありません。機密度の高いリソースに保護レベルを追加できる、多要素認証 (MFA) もサポートします。MFA は、不正アクセスのアラート、IP ホワイトリスト、2 つ目の認証要素としての携帯電話やSMS など、複数のサポートサービスを提供します。

アプリケーションプロキシの 3 つ目のメリットは、移動体通信ネットワークとオンプレミスネットワークを分離できることです。アプリケーションプロキシ自体は Azure AD に常駐し、コネクターが保護されたリソースに直接アクセスするため、バックエンドサービスは直接公開されません。最後に、アプリケーションプロキシは、DoS 攻撃に対する保護を提供し、調整、キュー、およびセッション管理を可能にします。

API 管理

保護されたリソースにアクセスできるようにする 3 つ目のアプローチは Azure API Management です。これは、オンプレミスのリソースへのプロキシとしても動作します。Azure API Management は、ファイアウォール内に実装されている Web サービスを外部に公開できるようにします。このオプションを機能させるには、オンプレミスの Web サーバーにいくつか変更を加え、Azure ポータルで API を作成および構成する必要があります。API は .NET Web API または Node.js のいずれかを使用して作成します。

まず、Azure API Management を使用して認証を行うことを考えます (基本認証を使って、オンプレミスの IIS ベースの Web サーバーに外部からアクセスできるようにします)。このシナリオを実現するための最初の手順として、オンプレミスの IIS Web サーバーに変更を加えて、基本認証を有効にします。IIS 内で、認証アイコンをクリックし、基本認証を表示してユーザーを追加します。Azure API Management は、この追加したユーザーのプロファイルを使用してオンプレミスのIIS にアクセスすることになります。

Azure API Management で利用できる次のアプローチは共有シークレット認証です。このアプローチでは、Azure API Management プロキシが秘密鍵を保管する必要があります。オンプレミスのバックエンド Web サービスへの接続を試みる前に、秘密鍵を HTTP ヘッダーに配置します。当然、バックエンド Web サービスは、HTTP ヘッダーから秘密鍵を取り出して認証要求を処理する必要があります。

Microsoft Azure の管理ポータルにアクセスして [API Management] (API 管理) セクションに移動し、メニューでポリシーを選択して、共有シークレット認証を実装します。ここではポリシーを追加することになります。このポリシーは、オンプレミスの Web サーバーに秘密鍵を送信するだけです。追加するポリシーの定義ファイルは XML ドキュメントです。

ハイブリッド接続

保護されたリソースにアクセスできるようにする 4 つ目のアプローチはほぼ間違いなく最もシンプルなアプローチで、ハイブリッド接続を使用します。ハイブリッド接続は、現在プレビュー版の Microsoft Azure BizTalk Services の機能です (図 4 参照)。ハイブリッド接続は Azure Service Bus Relay テクノロジを利用して、オンプレミスのプロセスと、Microsoft Azure Mobile Services のサービスまたは Azure Web Sites のサイトとの間にシンプルかつセキュアで、効果的な接続を作成します。ハイブリッド接続を使用して、SQL、Oracle、SAP などのデータベースや ERP ソリューションを含め、接続に TCP や HTTP を利用する任意のオンプレミスリソースに接続できます。

図 4 Microsoft Azure BizTalk Services - ハイブリッド接続

要件は、静的 TCP ポート (SQL Server のポート 1433など) を経由してオンプレミスのプロセスにアクセスできるようにすることです。Node.js、Java、.NET Framework など、任意のフレームワークを使用してリソースに接続できます。Service Bus Relay のほとんどの構成要件は、ハイブリッド接続によって抽象化されます。オンプレミスのプロセスのソースコードを変更する必要はありません。

ハイブリッド接続を使用するには、Microsoft Azure の管理ポータルで少量のメタデータを構成します。プロセス (SQL Server、MySQL、Web サービスなど) をホストするエージェントをサーバーにインストールします。内部では、認証に SAS キーを使用する Service Bus Relay 接続が実行されています。ポータル内でサービス側のキーとクライアント側のキーを個別にローテーションできます。Service Bus Relay を使用するため、受信エンドポイントやプロキシは必要ありません。

セットアップを簡単にし、開発者の労力を少なくするのであれば、ハイブリッド接続が適しています。そのうえ、ハイブリッド接続は無料レベルの Azure BizTalk Services で利用できるため、送信帯域幅の料金を支払うだけで、コスト効率よく使用できます。

デモ

最初に約束したように、ネイティブ iOS アプリと AMS バックエンドプラットフォームを使用して、今回示したテクニックのデモを行います。デモでは、ハイブリッド接続を使用するオンプレミスの Web サービスとオンプレミスの SQL Server を追加します。説明を簡潔にするために、既存のリソースの利用については、AMS チームのチュートリアル (bit.ly/1mK1LQF、英語) を参照してください。AMS チームのチュートリアルを参照すると、以下で構成される完全なソリューションをビルドするための追加のチュートリアル資料へのリンク (https://azure.microsoft.com/ja-jp/documentation/articles/mobile-services-dotnet-backend-ios-get-started/ と https://azure.microsoft.com/ja-jp/documentation/articles/mobile-services-ios-get-started-data/) が見つかります。

AMS サービスとしてインストールされ Azure AD テナントに登録される Web API バックエンド
同じ Azure AD テナントに登録されるネイティブ iOS アプリ
テナント内での Web API と AMS サービス間の双方向リンク

いくつか手順が必要です。まず、Microsoft Azure 管理ポータルでメタデータを作成します。次にネイティブ開発ツール (Visual Studio、Xcode、Android など) を使用して実際のアプリを作成します。これらの手順を完了したら、Azure AD の資格情報を入力して iOS アプリに認証を求める作業システムが完成します。その後の作業項目として CRUD 操作の実装などを考えます。図 5 のコードをモバイルサービスのコードに追加します。

図 5 ハイブリッド接続経由で保護されたリソースにアクセスするクライアントコード

// Use the SQL Server connection
try
{
  SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder();
  builder["Data Source"] = "myserver";
  builder["Integrated Security"] = false;
  builder["Initial Catalog"] = "mydb";
  builder["User ID"] = "greg";
  builder["Password"] = "S3cr3t";
  int count = 0;
  string query = "SELECT COUNT(*) FROM mytable";
  using (SqlConnection conn = new SqlConnection(builder.ConnectionString))
  using (SqlCommand cmd = new SqlCommand(query, conn))
  {
    conn.Open();
    cmd.CommandType = System.Data.CommandType.Text;
    count = Convert.ToInt32(cmd.ExecuteScalar());
  }
  string results = string.Format("Count of records in mytable is {0}", 
    count);
  Services.Log.Info(results);
}
catch (Exception ex)
{
  Services.Log.Error(ex.Message);
}
// Use the Web service connection
try
{
  const string URL = "http://mydevbox:31106/";
  HttpClient client = new HttpClient();
  client.BaseAddress = new Uri(URL);
  client.DefaultRequestHeaders.Accept.Clear();
  client.DefaultRequestHeaders.Accept.Add(
  new MediaTypeWithQualityHeaderValue("application/json"));
  string response = await client.GetStringAsync("api/values/5");
  Services.Log.Info("Accessing the web service succeeded.");
}
catch (Exception ex)
{
  Services.Log.Error(ex.InnerException.Message);
}

SQL Server の接続情報と Web サービス (シンプルなテンプレート Web サービス) のアドレス指定に必要なのは、ハイブリッド接続の名前だけです。

まとめ

BYOD の世界では ID がますます重要になります。ビジネスでは、職場でモバイルデバイスを利用できるようにすることがますます求められています。こうしたハイブリッド環境に置かれることでますます複雑になります。重要なリソースはクラウドにもオンプレミスにも存在します。認証はクラウドまたはオンプレミスのいずれか、または両方で行う必要がでてきます。保護されたリソースには、ビジネスアプリ、オンプレミスで実行するサービス、クラウドでホストされる Web サービスなどがアクセスします。多くのバリエーションが考えられるため、複数の柔軟なアプローチが必要になります。

今回の実装の完全な詳細については、ブログ投稿「Go Live on Azure」(Azure に取り組む) (bit.ly/1rVbtCp、英語) とこのトピックを Java に基づいて説明したブログ投稿 (bit.ly/1zW7XpZ、英語) を参照してください。

Greg Oliver は、2010 年に Microsoft Azure の ISV 組織に参加しました。彼は、企業の移行の計画や実装をサポートすることに多くの時間を費やしています。最近は、有名なコンシューマーゲーム企業で同社のプロバイダーを競合プロバイダーから移行する作業に取り組んでいます。マイクロソフトに参加する前は、新興企業のテクノロジパートナーを務めていました。

Bruno Terkaly は、デバイスに依存しない、業界をリードするアプリケーションやサービスを開発できるようにすることを目標にするマイクロソフトのプリンシパルソフトウェアエンジニアです。テクノロジが実現可能かどうかという視点を通り越して、米国で最高のクラウド商談やモバイル商談を進めることを担当しています。ISV が評価、開発、配置を行う際に、アーキテクチャに関するガイダンス提供したり、技術的な細かいサポート作業を行うことによって、パートナーがアプリケーションを市場に投入できるようにサポートしています。また、フィードバックを提供したり、ロードマップに影響を与えて、クラウドやモバイルのエンジニアリンググループと密接に連携することも行っています。

この記事のレビューに協力してくれたマイクロソフト技術スタッフの Santosh Chandwani に心より感謝いたします。