インテル® mashery™ap i ゲートウェイモバイル・ミドルウェア...

1

目的

この資料は、社員向けのBYOD（Bring Your Own Device）、あるいは顧客、パートナー、開発者向けの、Webベースのエンゲージメント・ポータルの、モバイル対応といったモバイル端末対応システムの導入に携わるビジネス/ IT担当者を対象としています。この資料の目的は、モバイル・アプリケーション開発を簡略化する手法と、適切なレベルのセキュリティーおよびユーザー体験の維持を両立する手法を示すことです。この資料を読むことにより、既存のデータ資産およびサービスを、外部開発者向けのAPIとして再パッケージし、新しい収益源創出のために有効な手法が選択できるようになります。

概要モバイル端末の用途は、音声通話と文字通信だけに限られません。また、スマートフォンのアプリケーションは、私的な用途やエンターテインメントにのみ使われるとは限りません。タブレットとスマートフォンは、企業の生産性を向上させるツールとして、ビジネスのあらゆる局面で利用されています。企業がモバイル

への移行を受け入れるにつれて、社内向けのサービスをモバイル端末に公開することで社員の生産性を向上し、社内向けだったAPIを外部の開発者コミュニティーに公開することで、新たな収益を生み出すことなどが可能になります。モバイル・ミドルウェアによって、企業はAPIを介して既存のデータとサービスを公開し、既存の固定的なWebアプリケーションをはるかに超える範囲まで浸透させることができます。

しかしながら、既存のモバイル向けWebアプリケーションは、パフォーマンス、拡張性、セキュリティー、ユーザビリティーの面でまだ力不足です。一方、ネイティブ・モバイル・アプリケーションやHTML5ベースのモバイル・アプリケーションは、より優れたユーザー体験をもたらしますが、これらのアプリケーションも、最終的にはAPIに主要なデータの配信を依存します。

モバイル・ミドルウェアは、急速に立ち上がりつつある、様々なテクノロジーによって構成され、情況によって異なる意味を持つことがあります。一部のベンダーにとっては、MBaaS

要旨この資料は、各種モバイル端末向けににアプリケーションを迅速に公開するAPIツールと、インフラストラクチャー（ミドルウェア）の評価を担当する方に、的確な情報に基づいた選択を可能にし、導入のための意思決定を支援します。前半の2章では、モバイル・ミドルウェア導入の一般的なビジネス・ユースケースについて説明します。それに続く各章では、業務要件と使用目的に合った、最適なソリューションを見つけるのに役立つ情報を紹介します。

内容● モバイル・ミドルウェア・アーキテクチャーの導入により収益を得る、企業のユースケース

● アーキテクチャー、パフォーマンス、セキュリティーのトレードオフについて

● 一般的なセキュリティー機能とモバイル対応時の推奨事項

● 導入を検討中の企業のためのチェックリスト

導入ガイドインテル® Mashery ™ API ゲートウェイ

インテル® Mashery™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

3


ケーションとして再実装されていきます。

先ほどのユースケース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 TCPover SSL

RESTful HTTP通信

バイナリー非同期メッセージング・コンポーネント

（インテル® Mashery API Gatewayに組み込まれた）Informatica Data Transformation

サービス・プロバイダーまたはC2DM（Cloud to Device Messaging）

安全なPaaS

軽量なHTTP/JSONに最適化されたアプリケーション・サーバー

iPhoneAndroid

BlackberryWindowsスマートフォン

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 ゲートウェイ

高速で変化するデータ/アクティビティー・ストリーム

4


データと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月

2011年7月

2011年10月

デスクトップモバイル

2012年1月

2012年4月

2012年7月

2012年10月

80%

60%

40%

20%

0%

図3：Webトラフィック占有率に占めるモバイル端末の割合

5


開発者の視点から見たモバイル・アプリケーション開発について検討し、開発者向けの対応とクロスプラットフォーム・アプリケーション開発に役立つツールを示します。

統合

最先端の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による複合サービス

6


すでにWebポータルを通じて外部向けサービスを公開している場合でも、追加のセキュリティー対策を検討する必要があります。現在のWebポータルの大部分は、プレゼンテーション層だけがインターネットに公開される伝統的な3層アーキテクチャーのバリエーションを採用しています。一方、多くのWebサービスはビジネスロジックをエンドポイントに配置し、サーバーを公開しています。APIサーバーはデータベースにアクセスするため、サーバーが攻撃を受けた場合、データ損失に直結します。

行し、透過的に1つのWebサービスコールに集約する高度な機能です。Webサービスの集約をサポートすることで、一部の論理機能をゲートウェイ内で実行できるため、アプリケーション・サーバーの増設を回避できます。

モバイルに適したセキュリティー

モバイル・アプリケーションは、通常は企業LANの外側で使用されることを想定しています。したがって、企業は、これまで企業内ファイアウォールによってインターネットからのアクセスが禁止されていたAPIとWebサービスを、インターネットに公開する必要があります。内部向けサービスについても保護することは推奨されますが、外部から接続されるAPIでは、悪意ある攻撃の起こりやすさは桁違いに大きくなります。

単なるAPIコールの転送と書き換えを超えた、より高度な機能を提供する一部のサービス・ゲートウェイは、軽量なロジックサーバーとして機能します。このモデルでは、ファイルまたはデータベースなどの内部データリソースのクエリーは、カタログ内の他のサービスとの整合性のある、RESTfulファサードを使用するWebサービスとして表現されます。モバイル・アプリケーションに関してもう1つの考慮すべき点は、複合サービスです。モバイル・プラットフォームは、他のタイプのクライアントに比べて処理能力が低く、帯域幅コストが高く、レイテンシーが大きくなります。したがって、モバイル・アプリケーションから複数のAPIコールを実行するコストははるかに高くなります。

複合サービスは、サービス・ゲートウェイが2つ以上のWebサービスのマッシュアップを実

ブラウザー

データベース・スレーブ1

データベース・スレーブN

プレゼンテーション層

論理（アプリケーション）層

パーシステンス層

データベース・マスター

Webサーバー

アプリケーション・サーバー




Webサーバー

Webサーバー







HTML5およびネイティブ・

アプリケーション

デリバリー /ガバナンス層



サービス・

ゲートウェイ








図5：従来の3層Webアーキテクチャー

図6：アプリケーションに最適化された2層アーキテクチャー

7


社などの企業は、顧客が自分のモバイル端末を使ってレジ精算できるようにしています。どちらのモデルでも、支払いはワイヤレス・ネットワーク経由で処理されるため、従来の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：内部サービス用のマルチゲートウェイ・アーキテクチャー

8


パフォーマンス

ここまでは、モバイル・アプリケーション向けの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を公開している

エンタープライズ・アプリケーション

エンタープライズ・プライベート・クラウド




HTML5およびネイティブ・アプリケーション

デリバリー /ガバナンス層



サービス・

ゲートウェイ








インターネット（レイテンシー）

図8：OAuthからエンタープライズIDへのマッピング

図9：オンプレミスでのレイテンシーに関する考慮事項

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コールに応じてゲートウェイが実行する各処理は、時間とリソースを消費します。ゲートウェイ層に複雑なワークフローを実装すると、応答時間に大きな影響を与え、パフォーマンスを低下させることがあります。ゲートウェイの性能は製品間で異なるため、各ベンダーが提供する最適化機能を慎重に検討する必要があります。検討すべき機




ブラウザー

エンタープライズ・プライベート・クラウドパブリッククラウド




Webサーバー

Webサーバー

Webサーバー

プレゼンテーション層









図10：SaaSゲートウェイ・サービス

10


ションの2つの手法がありました。すでに説明したように、Webブラウザーは、多くの場合、低レベルのユーザー体験しか提供できません。一方、ネイティブ・アプリケーションは、基盤となるプラットフォームから一貫性のある言語や機能、SDKのサポートが受けられないため、移植性が失われがちです。

HTML5は、複数のモバイル端末をターゲットとするアプリケーション開発において、実用的なソースとして現れたもので、加速度センサーや位置情報取得などのモバイル端末が備えている機能を活用できます。HTML５の利点は、HTML5コミュニティーの幅広いサポートを活用できることと、多数のライブラリーやフレームワークを、使いやすいライセンスで利用できることです。HTML5ベースのアプリケーションは、構築とパッケージングが完了すれば、ネイティブ・モバイル・アプリケーションと同じように、稼働中のモバイル端末上で配布およびアクセスできます。

モバイル・アプリケーション開発者は、アーキテクチャー/設計→プログラミング→テスト→デバッグ→パッケージ→実機テスト→アップデート、という開発サイクルを実行します。実機テストを除いた開発サイクルのかなりの部分は、デスクトップ上で実行されます。

モニタリングとメータリング

従業員と外部開発者のどちらにAPIを公開する場合も、パフォーマンスと使用回数の指標は必要不可欠です。いずれの場合も、APIの使用回数はアプリケーションとAPIそのものの人気の指標になります。このデータはキャパシティー・プランニングにも有益です。

アクセスに対して課金する場合、開発者は通常は使用したものに応じて料金を支払うため、これらの指標はさらに重要になります。したがって、APIプロバイダーとアプリケーション開発者の両方に、長時間にわたる使用回数のモニタリングが必要です。無償のAPIに関する使用回数の情報も、何が人気があり、何が人気がないかを判断するのに役立ち、将来投資すべき分野を示唆します。

ドキュメントへのアクセス回数やAPIのエラー率など、他の測定基準により、問題に予防的に対処する機会が得られます。

クロスプラットフォーム開発モバイル・ミドルウェアに関する最後のコンポーネントは、アプリケーション開発となります。モバイルアクセスを実現するために、これまでWebブラウザーとネイティブ・アプリケー

教育とドキュメント化

アプリケーション開発者は、多様な情報源からのドキュメントを必要としています。ブログ、ディスカッション・フォーラム、Wikiは、公式の情報源を補強し、しばしばそれらに取って代わるものです。これらの情報源の内容は、開発コミュニティーによって大きく異なります。APIポータルを評価する際は、柔軟性と拡張性を追求することをお勧めします。理想的には、こういった外部の情報源へリンクし、ポータルの一部として取り込めるような機能が望まれます。

コラボレーティブ・ポータル（すなわち、ドキュメントの「クラウドソーシング」が可能なポータル）は、多くの開発者にコミュニティーの感覚を育てるでしょう。また、コミュニティーの貢献により、実際の使用シナリオやサンプルコードを組み込むことで、ドキュメントの品質も向上します。

しかし、優れたドキュメントが用意されていても、開発者が必要な情報に常にアクセスできるとは限りません。開発者が必要なときに必要な情報を確実に見つけられるようにするには、ポータルに検索機能が組み込まれている必要があります。

さらに、開発者は実際のコードやサンプルコードを試したがるものです。APIポータルがドキュメントからコールを直接実行できる機能を備えていれば、開発者はポータルと開発環境の間を行き来しなくても容易に例を理解できるようになります。

開発者のアプリケーションiOS*Amazon*Android*Windows* 8Nook*

Facebook*Appup*Chrome*WebApp

インテル® Mashery™

API ゲートウェイ

インテル® Mashery™API マネジメント

図11：クライアント開発のワークフロー

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に変換する機能をサポートしていますか？

12


表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資産のセキュリティー、パフォーマンス、開発者の参画意欲の最大化を求める企業にとって理想的な高性能アーキテクチャーを提供します。

詳細情報（英語）インテル® Mashery™：http://services.intel.com/インテル® XDK：http://software.intel.com/html5/アメリカ合衆国：855-229-5580

本資料に掲載されている情報は、インテル製品の概要説明を目的としたものです。本資料は、明示されているか否かにかかわらず、また禁反言によるとよらずにかかわらず、いかなる知的財産権のライセンスも許諾するものではありません。製品に付属の売買契約書『Intel's Terms and Conditions of Sale』に規定されている場合を除き、インテルはいかなる責任を負うものではなく、またインテル製品の販売や使用に関する明示または黙示の保証（特定目的への適合性、商品適格性、あらゆる特許権、著作権、その他知的財産権の非侵害性への保証を含む）に関してもいかなる責任も負いません。インテルによる書面での合意がない限り、インテル製品は、その欠陥や故障によって人身事故が発生するようなアプリケーションでの使用を想定した設計は行われていません。

インテル製品は、予告なく仕様や説明が変更されることがあります。機能または命令の一覧で「留保」または「未定義」と記されているものがありますが、その「機能が存在しない」あるいは「性質が留保付である」という状態を設計の前提にしないでください。これらの項目は、インテルが将来のために留保しているものです。インテルが将来これらの項目を定義したことにより、衝突が生じたり互換性が失われたりしても、インテルは一切責任を負いません。この情報は予告なく変更されることがあります。この情報だけに基づいて設計を最終的なものとしないでください。本資料で説明されている製品には、エラッタと呼ばれる設計上の不具合が含まれている可能性があり、公表されている仕様とは異なる動作をする場合があります。現在確認済みのエラッタについては、インテルまでお問い合わせください。最新の仕様をご希望の場合や製品をご注文の場合は、お近くのインテルの営業所または販売代理店にお問い合わせください。本資料で紹介されている注文番号付きのドキュメントや、インテルのその他の資料を入手するには、1-800-548-4725（アメリカ合衆国）までご連絡いただくか、http://www.intel.co.jp/を参照してください。

©2014 Intel Corporation. 無断での引用、転載を禁じます。Intel、インテル、Intelロゴ、Masheryは、アメリカ合衆国および/またはその他の国におけるIntel Corporationの商標です。* その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

インテル株式会社〒100-0005 東京都千代田区丸の内3-1-1http://www.intel.co.jp/

2014年11月330833-002JA

JPN/1411/PDF/SE/SnSBD/KN

詳細情報 :

インテル® Mashery™ API 製品情報ページ: http://www.intel.co.jp/api

導入に関するお問い合わせは、インテルの営業担当者、インテル® Mashery™リセラー、または[email protected]までお問い合わせください。

http://services.intel.com/

http://services.intel.com/

http://software.intel.com/html5/

http://software.intel.com/html5/

http://www.intel.co.jp/

インテル® mashery™ap i ゲートウェイ モバイル・ミドルウェア...

Documents

インテル® mashery™ap i ゲートウェイモバイル・ミドルウェア...