目的
この資料は、社員向けのBYOD（Bring Your Own Device）、あるいは顧客、パートナー、 開発者向けの、Webベースのエンゲージメン ト・ポータルの、モバイル対応といったモバイ ル端末対応システムの導入に携わるビジネ ス/ IT担当者を対象としています。この資料 の目的は、モバイル・アプリケーション開発を 簡略化する手法と、適切なレベルのセキュリ ティーおよびユーザー体験の維持を両立する 手法を示すことです。この資料を読むことに より、既存のデータ資産およびサービスを、外 部開発者向けのAPIとして再パッケージし、新 しい収益源創出のために有効な手法が選択 できるようになります。
概要
モバイル端末の用途は、音声通話と文字通信 だけに限られません。また、スマートフォンの アプリケーションは、私的な用途やエンターテ インメントにのみ使われるとは限りません。タ ブレットとスマートフォンは、企業の生産性を 向上させるツールとして、ビジネスのあらゆる 局面で利用されています。企業がモバイル への移行を受け入れるにつれて、社内向け のサービスをモバイル端末に公開することで 社員の生産性を向上し、社内向けだったAPI を外部の開発者コミュニティーに公開するこ とで、新たな収益を生み出すことなどが可能 になります。モバイル・ミドルウェアによって、 企業はAPIを介して既存のデータとサービス を公開し、既存の固定的なWebアプリケー ションをはるかに超える範囲まで浸透させるこ とができます。 しかしながら、既存のモバイル向けWebアプ リケーションは、パフォーマンス、拡張性、セ キュリティー、ユーザビリティーの面でまだ力 不足です。一方、ネイティブ・モバイル・アプ リケーションやHTML5ベースのモバイル・ア プリケーションは、より優れたユーザー体験を もたらしますが、これらのアプリケーションも、 最終的にはAPIに主要なデータの配信を依存 します。 モバイル・ミドルウェアは、急速に立ち上がり つつある、様々なテクノロジーによって構成さ れ、情況によって異なる意味を持つことがあ ります。一部のベンダーにとっては、MBaaS要旨
この資料は、各種モバイル端末向けににアプリケーションを迅速に公開するAPIツールと、インフラ ストラクチャー（ミドルウェア）の評価を担当する方に、的確な情報に基づいた選択を可能にし、 導入のための意思決定を支援します。前半の2章では、モバイル・ミドルウェア導入の一般的な ビジネス・ユースケースについて説明します。それに続く各章では、業務要件と使用目的に合っ た、最適なソリューションを見つけるのに役立つ情報を紹介します。内容
●モバイル・ミドルウェア・アーキテク
チャーの導入により収益を得る、
企業のユースケース
●アーキテクチャー、パフォーマンス、
セキュリティーのトレードオフに
ついて
●一般的なセキュリティー機能と
モバイル対応時の推奨事項
●導入を検討中の企業のための
チェックリスト
インテル
® Mashery™API
ゲートウェイ
モバイル・ミドルウェア導入ガイド
とサービスを、どのように安全に公開する か。 ●コンプライアンスと企業ガバナンスは、モバ イル端末に公開されるデータにどのような 影響を与えるか。 ●外部APIによって提供される追加機能をど のように組み込むか。 ●どのくらいの数の端末での利用が予想され るか。インフラストラクチャーをどのように 拡張するか。 これらの問いに答えるには、ビジネス、デー タ、インフラストラクチャー、アプリケーション、 セキュリティー・アーキテクチャーの整合性を 確保する必要があります。また、企業内で のモバイル端末やモバイルアプリの役割が増 すにつれて、追加機能に合せて新しいアプリ ケーションをすぐに追加できるように、ソリュー ションには十分な拡張性を確保しなければな りません。 ユースケース
1
：社員の生産性 モバイル端末は、どこからでも企業リソースへ のアクセスを可能にし、社員は企業内にある データをいつでも参照することができます。多 くの企業にとって、電子メール、予定表、連 絡先の機能ではもはや不十分です。基幹業 務アプリケーションが、企業データへ安全にア クセスする機能を備えていれば、社員の生産 性はさらに向上します。モバイル端末には、 効率向上をもたらす機能が組み込まれてお り、生産性をより向上させることができます。 例えば一般的なの企業において、モバイル端 末の位置情報を利用して、会議室予約など の社内システムなど、位置の影響を受けるリ ソースの利用を最適化できます。 電力・水道会社などは、停電・断水や容量利 用率などの重要な現地情報を、現場作業員 のスマートフォンおよびタブレットに直接送信 できます。さらに、大規模な営業部隊を擁す る企業では、タブレットやスマートフォンを使用 して、従来のWebアプリケーションではでき なかった、比較販売などの支援が可能になり ます。（Mobile Backend as a Service）を モ バ イル・ミドルウェアとして紹介しています。こ れは基本的にはモバイル開発者のニーズに 合わせて調整されたPaaS（Platform as a Service）です。他のベンダーは、モバイル・ ミドルウェアを、モバイル端末によってただち に利用可能なAPIの集合体として定義してい ます。ここでは、図1に示した全体概要図を 元に、API、API管理、ソフトウェア開発を含 む、モバイルデバイス向けのアプリケーション 開発をサポートする、エンドツーエンドのソ リューションを考えます。本書における、モ バイル・ミドルウェアの定義は、従来のアプリ ケーション・サーバーおよびWebサーバー・ インフラストラクチャーに相当するものであり、 従来のエンタープライズ・ソフトウェア・アー キテクチャーの新しいアーキテクチャー基盤で す。
企業内でのモバイル活用
モバイル・アプリケーションは、当初はゲーム を楽しんだり情報を入手するためのものでし たが、最近では企業内のビッグデータとのや り取りに使用されることが増えています。この ようなエンタープライズ・モバイル・アプリケー ションには、既存のエンタープライズ・アプリ ケーションが備えているのと同レベルのセキュ リティーとパフォーマンスが必要です。 モバイル・ミドルウェア・プラットフォームの導 入を考えるとき、企業のシステム設計者は、ま ず次のような問題を検討する必要があります。 ●対象ユーザー（社員または顧客）に確実に リーチするには、どうすればいいか。 ●さまざまなフォームファクターを持つ多様な 端末で、どのようにアプリケーションを機能 させるか。 ●外部APIとアプリケーションの依存関係は あるか。依存関係がある場合、アプリケー ションのビジネス継続性をどのように確保す るか。 ●モバイル・アプリケーションのパフォーマンス をどのように最適化するか。 ●モバイル・アプリケーションに必要なデータ目次
概要. . . 1
企業内でのモバイル活用. . . 2
ユースケース1
：社員の生産性. . . 2
ユースケース2
： 外部からのアクセス. . . 3
ユースケース3
：API
の収益化. . . 4
モバイル・ミドルウェアのユースケース. . 5
統合. . . 5
モバイルに適したセキュリティー. . . 6
データ保護. . . 7
認証とID . . . 8
パフォーマンス. . . 8
開発者向けの対応. . . 9
発見. . . 9
オンボーディング. . . 9
教育とドキュメント. . . 10
モニタリングとメータリング. . . 10
クロスプラットフォーム開発. . . 10
まとめ：モバイル・ミドルウェア. . . 11
モバイル・ミドルウェアの チェックリスト. . . 11
スポンサーシップ. . . 13
ケーションとして再実装されていきます。 先ほどのユースケース1と比較したとき、社内 ユーザーがアクセスするサービスの範囲は小 さくなる一方、規模とセキュリティーの問題は はるかに大きくなります。また、デジタルネイ ティブ（物心ついた頃からデジタルツールに親 しんでいた世代）のユーザーは、外部のIDプ ロバイダーやソーシャル・ネットワーキングなど の外部クラウドサービスが統合されることを待 ち望んでいます。 外部ユーザーは、ユーザー体験の問題につ いてもはるかに不寛容です。このため、顧客 にアプリケーションを提供する際は、パフォー マンス、セキュリティー、可用性が極めて重要 になります。 ションとサービスの間で緩やかに結合された ポイント・ツー・ポイント接続を使用していまし た。いずれにしてもESBは、通常は大規模な モバイル・セキュリティーや、外部からの接続 を念頭に置いて設計されていません。 ユースケース
2
：外部からのアクセス これまでは、多くの企業がセルフサービス型 のWebエンゲージメント・ポータルを顧客に 提供してきました。このポータルは、商取引 や基本アカウント管理用途に使用され、最終 的にはエンタープライズ・サービスに接続され ます。モバイルブラウザーからのアクセスが増 大するにつれて、平凡なユーザー体験しか提 供できなかったポータルも、ネイティブ・アプ リケーションまたはHTML5モバイル・アプリ モバイルアクセスの第1段階は既製のソフト ウェア・パッケージを使って実現されましたが、 次の段階でははるかに多くのカスタムコード が使われる見込みです。図2に示すように、 2011年11月のForrester社の調査による と、半数以上の企業が独自のモバイル・アプ リケーションを社内で開発しています。これら のアプリケーションは、（既存のSOAPアプリ ケーションから、新たに開発されたRESTful APIに至るまでの）バックエンド・サービスの 組み合わせと、salesforce.comなどのクラウ ドでホスティングされるサービスにアクセスす る必要があります。 企業ユーザーがサービスに接続するには、こ れまでは設置済みの社内サービス用のESB（Enterprise Service Bus）か、アプリケー
図1： モバイル・ミドルウェアのリファレンス・アーキテクチャー
企業
ロード バランサー モバイル向けに 調整されたWeb サーバーファーム APIキー IDトークン マッピング シームレスな 連携 AAA Raw TCP over SSL RESTful HTTP通信 バイナリー非同期 メッセージング・ コンポーネント （インテル® Mashery API Gatewayに組み 込まれた）Informatica Data Transformation サービス・プロバイダーまたはC2DM（Cloud to Device Messaging）
安全なPaaS 軽量なHTTP/ JSONに最適化 されたアプリケー ション・サーバー iPhone Android Blackberry Windows スマートフォン Androidおよび iOSタブレット Mashery DCEファーム インテル® TXT モバイル・アプリケー ション・デバイス XDK Mashery Datacenter Edition（クライアント） ネ ッ ト ワ ー ク・ フ ァ イ ア ウ ォ ー ル NoSQL / RDBMSパー システンス層 またはMQ 開発者コミュニティー によるAPIの検証、利 用、監視を促進 WebモバイルSSO向 けのSAMLアサーショ ンを生成 プッシュ通知アラートと OTA（Over The Air） アップデートを送信 統一的なRESTful API を安全に公開、SLAの 適用およびレスポンス・ キャッシング Webモバイル・アプリケー ション向けに最適化され たコンテンツを配信 HTTPパフォーマンスを数百万台規模の機器に 対応できるように調整 モバイル対応データ・フォーマットを生成 クラウド・プロバイダーから のコンテンツを安全に仲介 インテル® Mashery™ API ゲートウェイ 高速で変化する データ/アクティビ ティー・ストリーム
データとAPIの収益化はモバイル市場では目 新しいことではありませんが、新しい端末およ びフォームファクターの急速な普及は、その 機会増大のスピードを速めています。顧客基 盤の拡大や、新たな収益源の発見が課題に なっているのであれば、外部開発者へのAPI の提供は良い結果をもたらす可能性がありま す。 これらのメリットをフルに実現するには、APIが セキュリティーと十分な機能を備えている必要 があります。サービスレベル（SLA）の適用、 レート制限、メータリング、スロットリングが必 要不可欠な機能になります。これらの機能に より、階層化されたサービスレベルが実現さ れ、限られたリソースの戦略的な配分が可能 になります。 をサポートし、自社コンテンツへの全域的な アクセスを可能にしました。その結果、同社 はプラットフォームの開発とサポートにかかる 追加コストを回避しながら、加入者の獲得と 収益の増大を実現しました。Evernote社、 Dropbox社、Instapaper社といった企業は、 外部の開発者に自社プラットフォームとの統 合を奨励することで、サービスの採用を増やし た企業の例です。 ほかにも多くの企業が、自社のデータが資産 であることを認識しています。Best Buy社は、 基幹業務プロセスの一部を開発者に公開し、 より緊密な協業により収益を上げようとしてい ます。CitySearch社はCityGrid社へと再編 成し、自社コンテンツを競合サービスに公開し ました。 ユースケース
3
：API
の収益化 企業は新たな収益源として、自社の内部 APIを外部の開発者に公開し始めています。SendGrid社、Twilio社、Urban Airship社 などの新興企業にとっては、APIが製品です。 既存企業がこの分野に参入する場合、次の2 つの選択肢があります。1つは、コミュニティー 形成と、ユーザー数の拡大を目的として、API を開発者に公開することです。もう1つは、社 内の基幹業務顧客だけが利用可能であった コア・コンピテンシーを活用して、APIを直接 収益へと結びつけることです。 Netflix社は、前者のモデルの最も有名な例 と言って差しつかえないでしょう。同社は、自 社のAPIを公開することで、多種多様な端末 図2：北米地域企業のモバイル・アプリケーションの調達先、Forrester社調査（2011年）
モバイル・アプリケーションの調達先
自社製またはインハウス開発、あるいはその両方 0% 10% 20% 30% 40% 50% 60% 外部開発者によって開発されたカスタム・アプリケーション システム・インテグレーターとの協力による開発 購入したモバイル・プラットフォーム上でモバイル・アプリケーションを開発 オフショア開発者によって開発されたカスタム・アプリケーション Webサイトデザイン会社との協力による開発 52% 33% 14% 13% 12% 11%STATCounterのグローバル統計
2011年1月から2012年12月までのモバイルとデスクトップの比較 100% 2011年 4月 20117月年 201110月年 デスクトップ モバイル 2012年 1月 20124月年 20127月年 201210月年 80% 60% 40% 20% 0% 図3：Webトラフィック占有率に 占めるモバイル端末の割合開発者の視点から見たモバイル・アプリケー ション開発について検討し、開発者向けの対 応とクロスプラットフォーム・アプリケーション 開発に役立つツールを示します。 統合 最先端のWeb開発者は、特定のプロバイ ダーのすべてのAPIが名称と機能に関して一 貫性を持つものとして扱います。通常これは、 api.<プロバイダー名>.comをルートとする一 貫性のあるURI構造の下ですべてのAPIを 公開することが含まれます。APIポータルで、 開発者が非標準のURIアドレスおよび構造を 見つけることも可能ですが、開発者コミュニ ティーを育てるのであれば、一貫性が重要に なります。少なくとも、サービス・ゲートウェイ はアプリケーション層スイッチとして機能し、企 業内の適切な「現実の」エンドポイントにコー ルを転送します。
ただし、API URIのDNS部分は、共通のAPI
プラットフォームが提供する部分的な機能に すぎません。ほとんどの既存企業では、開発 チームが広範囲にわたる規則を採用し、発展 を続ける一連の標準に合わせてAPIを開発し ています。より良い開発体験を提供するため、 サービス・ゲートウェイはAPI要求および応答 を書き換え、REST/JSONなどの一貫性のあ るファサードを確立します。 る決め手になったかにかかわらず、従来の Web/データサービスが、モバイル端末によっ てすぐに利用できるものでないのは明らかで す。ここで、企業には次の2つの選択肢があ ります。1つは、各サービスを互いに独立して 修正することです。もう1つは、モバイルアク セスへのギャップに橋を架ける、ミドルウェア 層を導入することです。ミドルウェア手法に よってどの程度開発コストが削減できるかは、 対象とするサービスの数と、必要な統合作業 のレベルによって決まります。これらの統合 機能により、セキュリティーとコンプライアンス のポリシーが均等に実装、適用、更新されて いることが保証されます。しかし多数のアプリ ケーションにカスタムコードを追加した場合、 これは簡単な作業ではありません。さらに、 モバイル・ミドルウェア層は拡張性を高めるメ カニズムを提供し、モバイル端末からの数千 件の接続を処理できます。 本資料の後半では、サービス・ゲートウェイが どのようにモバイル・ミドルウェア戦略の中核 となる機能を提供し、これらのユースケース をサポートするかを検討します。特に、サー ビス・ゲートウェイが、モバイル・アプリケー ション開発者が使用できる一連のRESTful Webサービスとしてデータソースを公開し、ど のように多様なデータソースの統合をサポー トするかに注目します。次に、エンタープライ ズ・データ・サービスにモバイルアクセスを提 供する場合に生じる、セキュリティーとパフォー マンスの課題について検討します。最後に、
モバイル・ミドルウェアのユースケース
従来のアプリケーション・デリバリーにはモノリ シックなアプリケーション・サーバーとESBが 使用されていましたが、モバイル・アプリケー ション・アーキテクチャーでは、Webサーバー とアプリケーション・サーバーの両方を含む ハイブリッド・モデルを利用します。便宜上、 ここではこのサーバーの集合体を「APIサー バー」と呼ぶことにします。これはSOAP、 RPC、HTTPを通じてWebサービスを配信す るサーバーという意味です。また、ESBはイン ターネット接続を想定して設計されていない ため、モバイル・アプリケーションの配信には 異なるミドルウェア層が必要です。ここでは、 WebベースのAPIへのアクセスを仲介するミ ドルウェアを「サービス・ゲートウェイ」と呼び ます。 さらに、どれほど成熟したサービス指向アーキ テクチャー（SOA）であっても、単一の企業内 に収容され、ファイアウォールの内側に配置す るように設計されるのが普通です。ユーザー は集中化されたエンタープライズ・カタログを 通じてサービスを見つけ、企業が発行したID （識別子）に基づいて権限を付与されます。 一方、モバイル・アプリケーションは、複数の プロバイダーのAPIを多数使用します。プロ バイダーのAPIのカタログを「APIポータル」 と呼びます。 どのユースケースがモバイル化戦略を採用す受信
API1の起動
返信
API2の起動
応答の集約
図4：2つのAPIによる複合サービスすでにWebポータルを通じて外部向けサー ビスを公開している場合でも、追加のセキュ リティー対策を検討する必要があります。現 在のWebポータルの大部分は、プレゼンテー ション層だけがインターネットに公開される伝 統的な3層アーキテクチャーのバリエーション を採用しています。一方、多くのWebサービ スはビジネスロジックをエンドポイントに配置 し、サーバーを公開しています。APIサーバー はデータベースにアクセスするため、サーバー が攻撃を受けた場合、データ損失に直結しま す。 行し、透過的に1つのWebサービスコールに 集約する高度な機能です。Webサービスの集 約をサポートすることで、一部の論理機能を ゲートウェイ内で実行できるため、アプリケー ション・サーバーの増設を回避できます。 モバイルに適したセキュリティー モバイル・アプリケーションは、通常は企業 LANの外側で使用されることを想定していま す。したがって、企業は、これまで企業内ファ イアウォールによってインターネットからのアク セスが禁止されていたAPIとWebサービス を、インターネットに公開する必要があります。 内部向けサービスについても保護することは 推奨されますが、外部から接続されるAPIで は、悪意ある攻撃の起こりやすさは桁違いに 大きくなります。 単なるAPIコールの転送と書き換えを超えた、 より高度な機能を提供する一部のサービス・ ゲートウェイは、軽量なロジックサーバーとし て機能します。このモデルでは、ファイルまた はデータベースなどの内部データリソースの クエリーは、カタログ内の他のサービスとの整 合性のある、RESTfulファサードを使用する Webサービスとして表現されます。モバイル・ アプリケーションに関してもう1つの考慮すべ き点は、複合サービスです。モバイル・プラッ トフォームは、他のタイプのクライアントに比べ て処理能力が低く、帯域幅コストが高く、レイ テンシーが大きくなります。したがって、モバ イル・アプリケーションから複数のAPIコール を実行するコストははるかに高くなります。 複合サービスは、サービス・ゲートウェイが2 つ以上のWebサービスのマッシュアップを実
ブラウザー
データベース・ スレーブ1
データベース・ スレーブN
プレゼンテー
ション層
ケーション）層
論理（アプリ
パーシステンス層
データベース・ マスターWeb
サーバー アプリケー ション・ サーバー ロードバランサー ロードバランサー ロードバランサーWeb
サーバーWeb
サーバー アプリケー ション・ サーバー アプリケー ション・ サーバー アプリケー ション・ サーバー データベース・ スレーブ1
データベース・ スレーブN
データベース・ マスターHTML5
および
ネイティブ・
アプリケーション
デリバリー
/
ガバナンス層
ケーション）層
論理（アプリ
ロードバランサー サ ー ビ ス ・ ゲ ー ト ウ ェ イ ロードバランサー ロードバランサー アプリケー ション・ サーバー アプリケー ション・ サーバー アプリケー ション・ サーバー アプリケー ション・ サーバーパーシステンス層
図5： 従来の3層Webアーキテクチャー 図6： アプリケーションに最適化された 2層アーキテクチャー社などの企業は、顧客が自分のモバイル端末 を使ってレジ精算できるようにしています。ど ちらのモデルでも、支払いはワイヤレス・ネット ワーク経由で処理されるため、従来のPOSモ デルとは異なる方法でデータを保護する必要 があります。 クレジットカード情報の処理に関するPCI（クレ ジットカード業界）基準を遵守するには、クレ ジットカードの詳細情報をトークン化する必要 があります。医療など、個人情報を扱うその 他の業種も、暗号化またはトークン化によって 機密情報を保護する必要があります。 暗号化とトークン化をサポートするゲートウェ イ・プロキシーも同様に、セキュリティーの強 化と監査範囲の縮小を実現します。ゲート ウェイは、実際のカード情報をトークンへ安全 にマッピングして維持します。つまり、他の場 所にトークン化機能を実装する必要はありま せん。 ウェイを安全にホスティングする必要があるた め、オンプレミスで導入できるゲートウェイを使 える場合にのみ実現可能であることに注目し てください。 また、セキュリティー・ゲートウェイを使用する と、すべてのAPIに対して一貫性のあるセキュ リティー・ポリシーを容易に適用できます。各 APIにカスタムコードを追加したり、各サー バーを個別に調整したりしなくても、一貫性の ある一連のチェックをゲートウェイ層で実行で きます。例えば、SQLインジェクション・スキャ ニング、オーバーフロー・スキャニング、クロス サイト・スクリプティング防止などのチェックの パッケージを定義できます。 データ保護 多くの小売事業者は、モバイルPOSの利用に より、レジ精算作業を効率化して、顧客サー ビス向上を図っています。Nordstrom社など の一部の企業は、クレジットカード・リーダー を備えたタブレット、またはスマートフォンをす べての店舗に導入しています。また、Apple サービス・ゲートウェイにより、企業は自社の モバイル対応システムへの攻撃を最小限に抑 えることができます。プロキシーモデルにより、 外部から接続される各APIについて、1台の サーバーまたはクラスターでデータ保護を行 いつつ、外部トラフィックに応答できます。こ れによって実際のWebサービスをさらに制限 し、ゲートウェイに対する接続と、DMZ（非武 装地帯）または企業イントラネットの内側の内 部システムに対する接続のみを許可すること ができます。 図7に示したこのモデルのバリエーションで は、1対のゲートウェイを使用して内部APIを 安全に公開し、DMZに導入されるAPIインス タンスの複製を不要にしています。このモデ ルでは、DMZの内側に第1のゲートウェイ、セ キュア・エンクレーブ（安全な孤立領域）の内 側に第2のゲートウェイが導入されます。イン バウンド・トラフィックは第1のゲートウェイ・ インスタンスへのアクセスを許可され、第2の インスタンスは第1のインスタンスからのトラ フィックのみを受け入れます。このモデルは、 セキュア・エンクレーブの内側で1つのゲート
インターネット
DMZ
セキュア・
エンクレーブ
API
サーバーAPI
DB
サーバーAPI
ゲートウェイ1
ゲートウェイ2
モバイル・
クライアント
要塞ホスト企業内
インターネット
管理ユーザーAPI
サーバー 図7：内部サービス用のマルチ ゲートウェイ・アーキテクチャーパフォーマンス ここまでは、モバイル・アプリケーション向け のWebサービス・ゲートウェイ導入の利点に 焦点を当ててきました。一方、このアーキテク チャーには潜在的なリスクと短所があります。 特に問題となるのがパフォーマンスです。間 接的プロセスとロジックのレベルが増えること で、伝搬と処理の両方にレイテンシーが生じ る可能性があるからです。 パフォーマンスの問題のうち、伝搬レイテン シーは比較的簡単に予測し、回避することが できます。サービス・ゲートウェイは、一般的 にSaaSまたはオンプレミスの2つのモデルで 利用可能です（図9）。 ムーズに処理できるOAuthが事実上の標準 である）ため、開発者とユーザーの両方に敬 遠される可能性があります。OAuth標準を採 用すれば、ユーザーと開発者の両方が直感 的に理解しやすくなります。しかし、エンター プライズ・アプリケーションは、通常はOAuth をサポートしていません。また、OAuthで Active Directoryを置き換えることも現実的 ではありません。 サービス・ゲートウェイは、OAuthからエンター プライズID管理システム（Active Directory など）へのブリッジとして機能し、ユーザーを OAuth認証情報にマッピングすることで、こ の問題を解決します。 認証と
ID
ID管理の問題は、しばしばモバイル・アプリ ケーションへの対応が遅れる原因となります。 ほとんどの企業は集中型のIDストアを標準 化し、Webベース・アプリケーション向けの NTLM認証や、X.509仕様、あるいはSAML といったWebサービス・セキュリティー仕様を 採用していますが、これらはいずれもモバイル 端末に対応していません。基本的なHTTP認 証またはSSL、あるいはその両方を使用して、 ユーザー情報とパスワード情報をサーバーに 渡す認証システムを構築することはできます が、セキュリティーはそれほど強固ではありま せん。しかも、これらの方式はWeb認証およ びアプリケーション認証の標準ではない（ス相互認証を
提供する
TLS
ネイティブ・モバイル・
アプリケーション
またはAPIコール
ゲートウェイ2
（OAuth認証情報を
ユーザー名にマッピング）
REST APIを
公開している
エンタープライズ・
アプリケーション
エンタープライズ・プライベート・クラウド データベース・ スレーブ1
データベース・ スレーブN
データベース・ マスターHTML5
および
ネイティブ・
アプリケーション
デリバリー
ガバナンス層
/
ケーション）層
論理（アプリ
ロードバランサー サ ー ビ ス ・ ゲ ー ト ウ ェ イ ロードバランサー ロードバランサー アプリケー ション・ サーバー アプリケー ション・ サーバー アプリケー ション・ サーバー アプリケー ション・ サーバーパーシステンス層
インターネット （レイテンシー） 図8：OAuthからエンタープ ライズIDへのマッピング 図9：オンプレミスでのレイテンシーに関する考慮事項ため、デザインを開発企業のコーポレートID およびブランドの標準に合わせて、ポータルデ ザインを変更可能かどうかも重要なポイントで す。 ポータルは、外部向けアプリケーションにとっ て価値があるのと同様に、内部開発者および 内部向けAPIにとっても価値があることについ ては、特に注目する必要があります。大規模 な企業などにおいては、グループ間の連携が 効率よく行われないなどの障壁がある場合、 しばしば重複する開発作業が行われることが あります。APIで集中化されたリポジトリーと、 対応する一連のモバイル・クライアント・アプ リケーションの環境であれば、社内開発者は すでに別のグループで開発済みのアプリケー ションを効率的に再利用可能になり、無駄な 開発作業を削減できます。 オンボーディング 開発者がAPIを使用することを決定したら、 次の手順はAPIへのアクセスの要求です。外 部開発者によるAPI利用が事業計画に含ま れていない場合は、ポータルへのアクセスは 社内のみに制限する必要があります。一方、 APIを外部に公開する場合は、ポータルは、ア クセストークンまたはキーを開発者に与える前 に、開発者を認証し、サービス条件への同意 を確認する必要があります。 能の例としては、暗号化命令のハードウェア・ アクセラレーションや、XML/JSON処理用の 効率的なソフトウェアなどがあります。
開発者向けの対応
モバイル・アプリケーション開発用の一連の APIを安全に公開できれば、次の手順は、開 発者がAPIを効率的に使えるようにすること です。この手順はAPIを開発者の目に留める ことから始まり、オンボーディング、トレーニン グ、モニタリング、メータリングで構成されま す。APIポータルは、一般的に以下の機能を 処理します。 利用すべきAPI
の発見 APIポータルの主な役割は、APIのサービス カタログを提供することです。このポータルに は、利用可能なAPIのリストと、SLA、利用者 情報、開発予定者に関する他の重要な詳細 情報が含まれます。ポータルを評価する際に は、開発者の使い勝手を考慮に入れる必要 があります。つまり、開発者が利用したAPI を見つけ出すのが容易か、利用上の制約に ついて、理解が容易か確認できるかなどのポ イントです。また、開発者側の環境に合わせ て、開発をスムーズに進めるためのサンプル の提供機能や、開発のノウハウがの共有がで きるか等も重要なポイントですです。さらに、 APIポータルは開発者にとっての入り口となる SaaSモデルでは、サービス・ゲートウェイはク ラウドに置かれるため、すべてのAPI要求は、 クライアントからクラウド・プロバイダーを通じ て、APIエンドポイントへ転送されます。これ により、各APIトランザクションに、100ミリ秒 以上の伝搬レイテンシーが加わる可能性があ ります。オンプレミスでの導入では、ゲートウェ イとAPIエンドポイントが同じデータセンター 内にあるため、伝搬レイテンシーの問題はあり ません。 クラウド上でホスティングされるAPIは、伝搬レ イテンシーの増大が避けられません。レイテン シーを最小限に抑えるには、サービス・ゲート ウェイと同じクラウド・プロバイダー、地域、お よび利用可能ゾーンを選択する必要がありま す。しかしながら、この場合アプリケーション・ ユーザーとの距離や、コスト、SLAなどといっ た他の意思決定要因をないがしろにする結果 を招きます。 処理レイテンシーの増大とスループットの低下 も、サービス・ゲートウェイを導入する場合の リスクとなります。APIコールに応じてゲート ウェイが実行する各処理は、時間とリソースを 消費します。ゲートウェイ層に複雑なワークフ ローを実装すると、応答時間に大きな影響を 与え、パフォーマンスを低下させることがあり ます。ゲートウェイの性能は製品間で異なる ため、各ベンダーが提供する最適化機能を慎 重に検討する必要があります。検討すべき機 データベース・ スレーブ1
データベース・ スレーブN
データベース・ マスターブラウザー
エンタープライズ・プライベート・クラウド パブリッククラウド ロードバランサーWeb
ロードバランサー
ロードバランサーサーバー
Web
サーバー
Web
サーバー
プレゼンテー
ション層
アプリケー ション・ サーバー アプリケー ション・ サーバー アプリケー ション・ サーバー アプリケー ション・ サーバー論理（アプリ
ケーション）層
パーシステンス層
インターネット （レイテンシー） （レイテンシー）インターネット 図10：SaaSゲートウェイ・サービスションの2つの手法がありました。すでに説明 したように、Webブラウザーは、多くの場合、 低レベルのユーザー体験しか提供できません。 一方、ネイティブ・アプリケーションは、基盤と なるプラットフォームから一貫性のある言語や 機能、SDKのサポートが受けられないため、 移植性が失われがちです。 HTML5は、複数のモバイル端末をターゲット とするアプリケーション開発において、実用的 なソースとして現れたもので、加速度センサー や位置情報取得などのモバイル端末が備えて いる機能を活用できます。HTML５の利点は、 HTML5コミュニティーの幅広いサポートを活 用できることと、多数のライブラリーやフレーム ワークを、使いやすいライセンスで利用できる ことです。HTML5ベースのアプリケーション は、構築とパッケージングが完了すれば、ネイ ティブ・モバイル・アプリケーションと同じよう に、稼働中のモバイル端末上で配布およびア クセスできます。 モバイル・アプリケーション開発者は、アーキ テクチャー/設計→プログラミング→テスト→ デバッグ→パッケージ→実機テスト→アップ デート、という開発サイクルを実行します。実 機テストを除いた開発サイクルのかなりの部 分は、デスクトップ上で実行されます。 モニタリングとメータリング 従業員と外部開発者のどちらにAPIを公開す る場合も、パフォーマンスと使用回数の指標 は必要不可欠です。いずれの場合も、APIの 使用回数はアプリケーションとAPIそのものの 人気の指標になります。このデータはキャパ シティー・プランニングにも有益です。 アクセスに対して課金する場合、開発者は通 常は使用したものに応じて料金を支払うた め、これらの指標はさらに重要になります。し たがって、APIプロバイダーとアプリケーション 開発者の両方に、長時間にわたる使用回数 のモニタリングが必要です。無償のAPIに関 する使用回数の情報も、何が人気があり、何 が人気がないかを判断するのに役立ち、将来 投資すべき分野を示唆します。 ドキュメントへのアクセス回数やAPIのエラー 率など、他の測定基準により、問題に予防的 に対処する機会が得られます。
クロスプラットフォーム開発
モバイル・ミドルウェアに関する最後のコン ポーネントは、アプリケーション開発となりま す。モバイルアクセスを実現するために、これ までWebブラウザーとネイティブ・アプリケー 教育とドキュメント化 アプリケーション開発者は、多様な情報源か らのドキュメントを必要としています。ブログ、 ディスカッション・フォーラム、Wikiは、公式の 情報源を補強し、しばしばそれらに取って代わ るものです。これらの情報源の内容は、開発 コミュニティーによって大きく異なります。API ポータルを評価する際は、柔軟性と拡張性を 追求することをお勧めします。理想的には、こ ういった外部の情報源へリンクし、ポータルの 一部として取り込めるような機能が望まれま す。 コラボレーティブ・ポータル（すなわち、ドキュ メントの「クラウドソーシング」が可能なポー タル）は、多くの開発者にコミュニティーの感 覚を育てるでしょう。また、コミュニティーの貢 献により、実際の使用シナリオやサンプルコー ドを組み込むことで、ドキュメントの品質も向 上します。 しかし、優れたドキュメントが用意されていて も、開発者が必要な情報に常にアクセスでき るとは限りません。開発者が必要なときに必 要な情報を確実に見つけられるようにするに は、ポータルに検索機能が組み込まれている 必要があります。 さらに、開発者は実際のコードやサンプルコー ドを試したがるものです。APIポータルがドキュ メントからコールを直接実行できる機能を備 えていれば、開発者はポータルと開発環境の 間を行き来しなくても容易に例を理解できるよ うになります。 開発者のアプリケーションiOS*
Amazon*
Android*
Windows* 8
Nook*
Facebook*
Appup*
Chrome*
WebApp
インテル® Mashery™ API ゲートウェイ インテル® Mashery™API
マネジメント 図11：クライアント開発のワークフローモバイル・ミドルウェアは、セキュリティー機 能、指標の提供、開発者のサポート、クロス プラットフォームの互換性などを提供すること で、こうした移行を容易にします。モバイル・ ミドルウェアは比較的新しい分野であり、包 括的なエンタープライズ・グレードのソリュー ションはほとんど存在しません。この資料の 目的は、企業が新しいサービスや従来のサー ビスをモバイル端末に公開する際の、API管 理ソリューションの評価に役立つ一連の推奨 事項を示すことにあります。
モバイル・ミドルウェアのチェックリスト
表1は、社内およびサービス・プロバイダーの トークン化で使用するオプションの検討、ま たベンダーのソリューションの比較に役立ちま す。 に対応したアプリケーションに変換する自動化 ツールも必要です。まとめ：モバイル・ミドルウェア
モバイル端末の急速な成長は、従業員の業 務力の強化、顧客対応の拡充、新たな収益 源の確保といった好影響を企業にもたらしま す。これらの変革を実現するためにAPIは重 要な役割を果たします。 しかし、企業のファイアウォールを越えてAPI を安全に公開する場合、慎重に行わないと、 新たなリスクが生じたりユーザー体験が低下 したりしかねません。また、モバイル端末の ベンダーは新しいフォームファクターやプラット フォーム機能を次々と生み出しているため、そ れに追従するのも容易ではありません。 HTML5モバイル・アプリケーション開発者は、 次のような課題に直面しています。 ●開発サイクル中に、複数の端末および画面 をエミュレートし、応答性の高いアプリケー ションを開発する ●デスクトップ開発プラットフォーム上で、ロ ケーション・サービスなどのモバイル端末の ネイティブ機能をエミュレートする● iOS*、Android*、Windows*、Tizen*な
ど、複数のOSに導入できるパッケージン グ・ターゲットを作成する ●ネイティブ端末上で最適なパフォーマンスを 達成する また開発者には、Objective-Cなどの既存の ネイティブ形式のアプリケーションをHTML5 表1：モバイル・ミドルウェアのチェックリスト タスクまたは機能 対応状況を記入 準備 導入するアプリケーションの対象は、社員ですか、顧客ですか、その両方ですか？ 公開する内部APIの初期セットをドキュメント化しましたか？
既存のAPIは、SOAPまたはREST、XMLまたはJSONを使用していますか？
APIとの統合
ソリューションは、SOAPからRESTへ、XMLからJSONへなど、必要なフォーマットを変換する機能を備えていますか？ ソリューションは、ファイアウォールを通して公開されるデータを制限するAPIコールのフィルタリング機能をサポートしていますか？ ソリューションは、実際には複数のバックエンドのAPIコールをマッシュアップして、１つのAPIとして表現できますか？
ミドルウェアは、HTML5ベースのモバイル・アプリケーション用のJSONPをサポートしていますか？
Microsoft* SharePoint*、Oracle* e-Business Suite、SAPなどの社内システムのデータを、モバイル端末で直接利用できる ようにする機能をサポートしていますか？
分析情報をモバイル端末に公開するために、HBaseやHadoopなどの分析システムとの安全な統合をサポートしていますか？ 従来のデータベース・システムのデータを、モバイル端末で利用できるようにする機能をサポートしていますか？
ID、位置情報、サービスレベルに基づいて、APIコールを制限する機能をサポートしていますか？
SOAP、JMS、FTP、Raw TCP、Customプロトコルなど、従来のサービスをRESTful APIとして公開する、プロトコル変換機能 をサポートしていますか？
WebSocketなどの高性能な全二重プロトコルをサポートしていますか？
API開発者向けポータル（SaaSおよびオンプレミス）の複数の導入オプションをサポートしていますか？
Word、Excel、PDF、HL7、EDI、フラットファイル、独自規格に基づくバイナリー・フォーマットなど、従来のデータ・フォーマット をJSONに変換する機能をサポートしていますか？
表1：モバイル・ミドルウェアのチェックリスト（続き）
タスクまたは機能 対応状況を記入
セキュリティー
クレジットカード情報（PANデータ）のトークン化をサポートしていますか？
インテル® McAfee Data Loss Prevention（または同等の機能）をサポートしていますか？
FIPSハードウェア・セキュリティー・モジュールとの統合をサポートしていますか？ 高性能のSSLターミネーション、およびSSLアクセラレーションをサポートしていますか？ インバウンドAPIコール上のHTTP、XML、JSONベースの脅威に対するコンテンツ攻撃保護をサポートしていますか？ メッセージ・レベルのセキュリティーと、フォーマット維持型の暗号化（FPE）をサポートしていますか？ インバウンド・データ上のアンチウイルスおよび、アンチマルウェア・チェック機能をサポートしていますか？ サービス拒否攻撃に対する、適応性の高い保護をサポートしていますか？ APIキーベースの認証をサポートしていますか？ OAuth 2.0をサポートしていますか？ 複数のフォームファクターをサポートしていますか。DMZセキュリティー用のアプライアンスと、クラウドへの導入用の仮想アプライ アンスをサポートしていますか？
APIキーから、LDAP、Active Directory、Kerberosトークンなどの従来のエンタープライズID管理認証情報へのマッピングを サポートしていますか？ その他 セキュリティーの専門知識が、ソリューション・プロバイダー（内部ソリューションの場合は企業）のコア・コンピテンシーになって いますか？ プロバイダーの財務状況は健全ですか？ リスク評価（PCI要件12.1.2）を更新し、トークン化と、トークン化ベンダーまたはアプリケーションが攻撃を受けた場合の潜在的 なリスクを反映させていますか？ セキュリティー意識向上トレーニング（PCI要件12.6）を更新し、トークン化を反映させていますか？ ベンダーは、PANデータを保護する責任（PCI要件12.8）を書面で承認する用意がありますか？ インシデント対応プラン（PCI要件12.9）を更新し、トークン化（トークン化の失敗、ベンダーの障害、物理的または論理的違反 など）を反映させていますか？
スポンサーシップ
インテル
® Mashery™
についてインテル® Servicesは、世界を代表するAPI
テクノロジーとサービスのプロバイダーです。 インテル® Servicesは、USA TODAY、Com cast、Hoover's、Klout、Associated Press、
RDIO、Travelocityなど、175社以上のトッ プブランドを顧客として、APIを活用した新し い収益チャネルの構築、市場投入の迅速化、 イノベーションの促進を支援しています。イン テル® Services独自の包括的なAPI管理手 法には、クライアントとの協力をを通じた収益 力の高いプラットフォーム戦略の構築、高速 で信頼性の高いAPIアクセスの確保、20万 人の開発者ネットワークとの関係の活用が含 まれます。 インテル
® Mashery™ API
ゲートウェイ インテル® Mashery™ API ゲートウェイは、 オンプレミスまたはクラウド上のアプリケー ション・サービス/APIを安全に公開または使 用できるように設計されたソフトウェア・アプラ イアンスです。この製品は、今日使用されて いる多種多様なモバイル・プラットフォーム、 オペレーティング・システム、プログラミング言 語と、従来のアプリケーションの間のギャップ を埋め合わせるモバイル・ミドルウェア設計パ ターンを実装します。従来の3層Webアーキ テクチャーは、OAuth、外部クラウドサービス の安全な統合と仲介し、（特にJSONコンテン ツの）高性能データ変換など、すべてのAPI とサービスのセキュリティーを扱う単一のアプ リケーション・プロキシーに集約されます。 インテル® Mashery™ API
マネジメント–
Data Center Edition
についてインテルは、API管理用として、市場をリード するインテル® Mashery™ APIマネジメント ソリューションを提供しています。APIを有 効化するオンプレミスのゲートウェイと、ホス ティングされるAPI管理サービスを組み合わせ てシームレスに統合することで、API資産のセ キュリティー、パフォーマンス、開発者の参画 意欲の最大化を求める企業にとって理想的な 高性能アーキテクチャーを提供します。
