目次


SaaS (Software as a Service) アプリケーションのセキュリティー要件を満たす

マルチテナントでのセキュアな認証と承認

Comments

はじめに

このトピックに関するスキルを磨いてください

このコンテンツは、皆さんのスキルを漸進的に磨いていくための Knowledge Path の一部です。次のリンクをご参照ください。 クラウド・コンピューティング: Software as a Service の紹介

IT に関するコストと作業を削減しようとするなかで構築された SaaS (Software as a Service) ビジネス・モデルは、ソフトウェア業界で大きな関心を呼んでいます。このモデルでは、アプリケーションの機能はインターネット経由のサブスクリプション・モデルとして提供されます。ビジネスはソフトウェアを所有せず、リモートから提供されるトータル・ソリューションをサブスクライブします。SaaS モデルでは、さまざまなプラットフォームやバージョンをサポートする必要がなくなるため、IT コストを削減することができます。ただし、SaaS アーキテクチャーではデータやプロセスが社外に存在するため、セキュリティーが極めて重要になります。

ソフトウェアの作成、利用、提供の方法を (従来のソフトウェア開発の方法とは) 変えつつある SaaS は、非常に大きな影響力を持った IT トレンドであることが明らかになりつつあります。SaaS アプリケーションの開発とエンタープライズ・アプリケーションの開発との重要な違いの 1 つは、SaaS アプリケーションがマルチテナントでなければならない点です。SaaS に関する他の重要な要件、つまりセキュリティー、カスタマイズ、SOA (Service-Oriented Architecture)、統合などは、SaaS アプリケーションのアーキテクチャーに影響を与えます。

この記事では、J2EE ベースのマルチテナント型 SaaS アプリケーションに関するアプリケーション・レベルのセキュリティー要件について、またそうした要件に対応するためのメカニズムについて説明します。

SaaS アプリケーションのセキュリティー要件

効率的なマルチテナント型 SaaS アプリケーションには、以下に挙げるようなセキュリティー要件があります。

  • システムはアクセス権に基づいて、アプリケーションの機能にセキュリティーを提供し、アプリケーションの機能へのアクセス制御を行う必要があります。
  • ユーザー・データはオンプレミス環境に存在する場合があります。

    システムは、オンプレミス環境に存在するユーザー・データを使ってユーザーを認証し、オンデマンド環境に存在するアクセス制御データを使って承認するメカニズムを提供する必要があります。

  • テナントがデータの隔離とコンプライアンスを強く要求しているときには、ユーザー・データはオンデマンド環境に置かれた各テナント専用のデータベースに格納される場合があります。

    システムは、ユーザーが属するテナント用に構成された別々のデータベース・レルムに対して、ユーザーの認証と承認を行うメカニズムを提供する必要があります。

  • ユーザー・データは以下のような共有データベースに存在する場合があります。
    • オンデマンド環境にあり、データベース・スキーマはテナントごとに異なる可能性がある。

      システムは、共有データベースに対する認証と承認を行うためのメカニズムを提供する必要がありますが、データベース・スキーマの構成はユーザーが属するテナントごとに異なります。

    • オンデマンド環境にあり、データベース・スキーマが共有されている。

      システムは、すべてのテナントに使用される共有データベースと共有スキーマに対してユーザーの認証と承認を行うためのメカニズムを提供する必要があります。

  • ユーザー・データは共有データベース内に存在する場合があります。
  • システムは、各テナントの管理者がそのテナントのユーザー・アカウントをユーザー・アカウント・ディレクトリーの中で作成、管理、削除できるようにするためのメカニズムを提供する必要があります。

要件に対応する

SaaS のアプリケーション・レベルのセキュリティー要件に対応するためには、アーキテクチャーによって認証と承認の要件に対応する必要があります。この記事では以下の 2 つのシナリオについて説明します。

  • ユーザー・アカウントのデータベースがオンデマンド環境にある場合

    このシナリオでは、カスタムで構築したセキュリティー・サービスをアーキテクチャーによって提供し、集中型でマルチテナントのユーザー・アカウント・データベースとテナント専用のデータベースに対してユーザーの認証と承認を行う必要があります。またこのアーキテクチャーでは、テナントがそのテナントのユーザー・アカウントをユーザー・アカウント・ディレクトリーの中で作成、管理、削除できるインターフェースも提供する必要があります。

    これは顧客にとってシングル・サインオンが重要ではない場合に推奨の方法で、一般ユーザー向きです。

  • ユーザー・アカウントのデータベースがオンプレミス環境にある場合

    このシナリオでは、テナントがデプロイするフェデレーション・サービスによってテナント自身のユーザー・ディレクトリー・サービスとのインターフェースを取ります。エンドユーザーがアプリケーションにアクセスしようとすると、そのテナントのフェデレーション・サーバーはそのユーザーをローカルで認証した後、SaaS フェデレーション・サーバーとのネゴシエーションを行い、署名付きのセキュリティー・トークンをそのユーザーに渡します。SaaS プロバイダーは、そのテナントのフェデレーション・サーバーが発行したセキュリティー・トークンを使用して承認を行います。

    これは顧客にとってシングル・サインオンが重要な場合に推奨の方法で、ビジネス・ユーザー向きです。

ユーザー・アカウントのデータベースがオンデマンド環境にある場合

なぜセキュリティー・ソリューションをカスタムで構築する必要があるのでしょう?重要な技術要件として、SaaS アプリケーションでは 1 つのインフラストラクチャーに複数のテナントが存在できるようでなければなりません。この要件に対応するために、SaaS プロバイダーが提供するメカニズムは、SaaS アプリケーションでサポートされるすべてのテナントのユーザーを収容する単一の SaaS アプリケーション・インスタンスを実行できるものでなければなりません。

図 1 は、ある SaaS アプリケーションの 1 つのインスタンスがどのようにして複数テナントのユーザーをサポートするかを示しています。セキュリティー・サービス (Security Service) はデフォルトの集中型データベース 1 (Database 1) を使用してテナント 1 (Tenant 1) とテナント 2 (Tenant 2) のすべてのユーザーをサポートします。それと同時に、テナント 3 (Tenant 3) とテナント 4 (Tenant 4) によるデータの隔離とコンプライアンスに対する強い要求に対処するため、テナント 3 (Tenant 3) のすべてのユーザーに対しては専用のデータベース 2 (Database 2) を使用し、テナント 4 (Tenant 4) のすべてのユーザーに対しては専用のデータベース 3 (Database 3) を使用するメカニズムを提供する必要があります。

図 1. 複数テナントのユーザーをサポートする
複数テナントのユーザーをサポートする

セキュリティー・フレームワークは、テナントごとに別のレルムを提供する必要があります。また、顧客が属するテナントに対して構成されたレルムを使用して、コンテキストに基づいてユーザーを認証するメカニズムを提供する必要があります。この場合のコンテキストというのは、そのアプリケーションのビジネス・オペレーションと使用環境を決定するパラメーター (テナント、業種、地理的場所など) の組み合わせです。

J2EE コンテナー・ベースのセキュリティー・フレームワークには制約があり、複数のセキュリティー・レルムを同時にアクティブにすることができません。主な J2EE コンテナーはすべて、複数レルムを構成するためのメカニズムを提供していますが、1 度に 1 つのレルムしかアクティブにすることができません。J2EE のセキュリティー・モデルはメソッド・パーミッションをベースにしているため、きめ細かいセキュリティー・アクセスを実現するのは煩雑な作業となり、非現実的です。

この制約を回避するには、JAAS (Java Authentication and Authorization Service) をベースとするカスタムのセキュリティー・サービスを構築することが必要になります。JAAS は、サービスがユーザーを認証し、ユーザーへのアクセス制御を行えるようにする一連の API です。JAAS ではアプリケーションと、そのアプリケーションで使用する認証および承認メカニズムとの間に抽象化レイヤーを配することにより、Java のセキュリティー開発を単純なものにします。

JAAS をベースにしたカスタムのセキュリティー・サービスを構築する

JAAS ベースのセキュリティー・サービスは、以下のセキュリティー動作を行うメカニズムを提供する必要があります。

  • ユーザーがビジネス機能にアクセスする前に、ユーザーを識別する。
  • ユーザーのアクセス制御リスト (Access Control List: ACL) を保持することで、機能とデータに対するアクセス権を付与する。
  • ユーザー、グループ、ACL の作成および保守をサポートする。
  • SaaS アプリケーションのマルチテナンシー要件に対応する。
  • 各テナントの管理者が、そのテナントのユーザー・アカウントをユーザー・アカウント・ディレクトリーの中で作成、管理、削除できるようにする。

SaaS アプリケーションに対するセキュリティー・サービスを構築する場合、他のエンタープライズ・アプリケーションとの重要な違いはマルチテナンシー要件に対処する必要がある点です。そのためには、セキュリティー・サービスは以下の項目に対応する必要があります。

  • ユーザー・コンテキストを取り込む手段の提供。

    繰り返しますが、コンテキストというのは SaaS アプリケーションのビジネス・オペレーションと使用環境を決定するパラメーター (テナント、業種、地理的位置など) の組み合わせです。

  • マルチテナント型データ・アーキテクチャーを作成するための、明確に異なる 3 つの手法の提供。

    テナントごとに専用のデータベースを提供する

    テナントごとに専用のデータベースが指定されます。これは顧客がデータの隔離を強く要求している場合に推奨される手法です。

    共有データベースと個別のスキーマを提供する

    共有データベースがすべてのテナントに使用され、各テナントはそのテナント用に作成された個別のスキーマによる一連のテーブルを独自に持つことができます。この手法と、テナントごとに専用のデータベースを持つ手法をサポートするために、セキュリティー・サービスは図 2 のデータベース・テーブルを使用することができます。

    図 2. 専用のデータベース・スキーマを持つ手法
    専用のデータベース・スキーマを持つ手法
    専用のデータベース・スキーマを持つ手法

    共有データベースと共有スキーマを提供する

    共有データベースと共有スキーマがすべてのテナントに使用されます。この手法では、すべてのテーブルにおいて、テナント ID 列によってすべてのレコードと対応するテナントとが関連付けられます。図 3 に、この手法をサポートするセキュリティー・サービスが使用できるデータベース・テーブルを示します。

    図 3. データベース・スキーマを共有する手法
    データベース・スキーマを共有する手法
    データベース・スキーマを共有する手法
  • 大部分のテナントの要件に基づいたデフォルトのデータ・アーキテクチャー戦略の選択。
  • 以下のメカニズムを備えた永続化フレームワークの使用。
    • データベースに接続するための戦略を構成によって複数用意することができるメカニズム。
    • インターフェース・ベースの DAO (Data Access Object) デザイン・パターンを使用して永続化ロジックを実装できるメカニズム。
    • dao.config XML 構成ファイルにより、DAO 論理名から実装の詳細へのマッピングを使ってさまざまな DAO 実装を組み込めるようにするメカニズム。
  • デフォルトのデータ・アーキテクチャー戦略に従ってデータベース操作を行うための基本 XML 構成ファイルの必要。
  • 他のデータ・アーキテクチャー戦略を使用したいテナントがデータベース操作を行うための、カスタマイズされた構成ファイルの提供。
  • 各テナントに固有の構成と拡張機能について記述した情報を取得する手段と、それらのカスタマイズされた構成を実行時にテナントのコンテキストに基づいて組み込む手段の提供。

ユーザー・アカウントのデータベースがオンプレミス環境にある場合

SaaS プロバイダーは、COTS (Commercial Off-The-Shelf: 既製品) としてのフェデレーテッド・サーバーを利用することで、異なるセキュリティー・ドメインに存在する多様なアプリケーションにフェデレーション・トークンをセキュアに転送することができます。SaaS プロバイダーは SSO ソリューションとして、オンデマンド環境のエンタープライズ顧客が使用する他の SSO ソリューションと相互運用な可能なフェデレーテッド・サーバーを使用する必要があります。オンプレミス環境に置かれるフェデレーション・サーバーは、そのサーバーに対応した、SaaS プロバイダーのネットワーク内にあるフェデレーション・サーバーと信頼関係を持つ必要があります。

ユーザー・アカウントのデータベースがオンプレミス環境にある場合には、以下のことも必要です。

  • サーブレット・フィルターを作成することにより、フェデレーテッド・サーバーを使用して認証済みのユーザーの名前を HTTP ヘッダーから取得し、有効なプリンシパルやサブジェクトを作成する。
  • JAAS (Java Authentication and Authorization Service) をベースにカスタムで構築されたセキュリティー・サービスを活用し、SaaS で承認を行うためのマルチテナンシー要件に対応する。
  • サーブレット・フィルターからセキュリティー・サービスの API (Application Program Interface) を呼び出して、ユーザーに対して承認を行う。
  • MVC (Model-View-Controller) デザイン・パターンをベースに、プレゼンテーション・フレームワークのコントローラー・サーブレットによってサーブレット・フィルターを構成し、受信したリクエストが必ずセキュリティー要件を満たすようにする。

まとめ

この記事では、J2EE ベースの SaaS アプリケーションにおけるアプリケーション・レベルのセキュリティー要件に対応するための戦略について説明しました。SaaS プロバイダーはこれらの戦略を使用することで、効率的なマルチテナント型 SaaS アプリケーションのセキュリティー要件に対応することができます。


ダウンロード可能なリソース


関連トピック

  • ロングテールを理解するためのアーキテクチャ戦略」(Microsoft、2006年4月) は、ソフトウェアを提供するための SaaS (Software-As-A-Service) モデル、上位レベルで見た SaaS アプリケーションのアーキテクチャー、また SaaS を開発、提供する上での課題やメリットについて解説しています。
  • Java の認証と承認についての概要を解説したドキュメントの中で JAAS が解説されています。
  • ウィキペディアの SaaS の項目には、SaaS の歴史、考え方、重要な特徴などが解説されています。
  • IBM Software Services for WebSphere について学んでください。
  • IBM は最先端のハードウェア、ソフトウェア、インフラストラクチャー技術を提供しています。これらの技術は皆さんの既存のビジネス・モデルに役立つだけではなく、SaaS を使い始める上にも役立ちます。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=811005
ArticleTitle=SaaS (Software as a Service) アプリケーションのセキュリティー要件を満たす
publish-date=04262012