クラウドの活用事例
2 IceWallクラウドデモセンターの構成とクラウド環境
2.1 構成
IceWallクラウドデモセンターは、次の3つの要素から構成されています。
- クライアント
- サーバー:IaaS
- サーバー:国内データセンター
クライアントは、アクセス元としてファットクライアント(いわゆるPC)のケースと、シンクライアントのケースがあります。いずれもインターネットからアクセスします。
サーバーは、2つの環境を利用しています。1つはAmazon Web Services(AWS)によるIaaS、もう1つはリアルな国内のデータセンターです。
後にご紹介するデモシナリオにその使い分けがありますが、基本的にはAWS上でSSOやIDMが完結して動作するように構成しています。そして国内データセンターはイントラネットでの利用を想定し、利用者環境という位置づけで使用しています。AWSと国内データセンターはソフトVPNで仮想的にLAN間接続しています。
これらの概念図は以下、図2のようになっています。
図2:クラウドデモセンターの構成(クリックで拡大) |
AWSと国内データセンターについては、以降で説明します。
2.2 Amazon Web Services(AWS)
IaaSは、AWSのAmazon Elastic Compute Cloud(EC2)を採用しました。さらに、データバックアップ用にAmazon Simple Storage Service(S3)を、国内データセンターとのセキュアなネットワーク接続にソフトウエアVPNも使用しました。
IceWallクラウドデモセンターコアテクノロジーはSSOやIDMですが、これらソリューションのソフトウエアを稼働させるために、LinuxやWindowsの仮想マシンが複数台必要でした。EC2でそれらの仮想マシンを必要に応じて追加しながらデモ環境をセットアップしました。またISVとの連携では、例えば他のソリューションと独立して動作させなければならない等、必要に応じてサーバーを増やすことがありますが、クラウドなら素早く対応が可能です。
逆に、AWSを利用する際の注意点として、以下が挙げられると思います。
- AWSの管理自体が難しい(設定が多い)
- IceWallクラウドデモセンターの開設時点では、AWSのデータセンターはアメリカにあり、日本からのアクセスにおいてはネットワークの帯域が細い(スループットが悪いと感じる)
- 基本的にオンラインドキュメントは英語である
- インターネット上にサーバーを立てる状態のため、要塞化設定が必須である(特に、ファイアウォールでのアクセス制御やサーバー管理用のアクセス管理などは重要と思われる)
- 仮想サーバーに固定IPアドレスを持ったとしても、Webサービスとして利用するためには外部からアクセス可能なURLを必要とするため、外部DNSなどの設定もする必要がある
IceWallクラウドデモセンターでは、Linuxサーバーを使用していますが、ファイアウォールでの通信制御に加え、管理のためにサーバーにアクセスする際には、公開鍵暗号方式でのSSHを使用しています。一時的にファイアウォールの設定を外すと、不特定多数の悪意のあるユーザーからSSHアタックを相当受けるような状況です。つまり、要塞化をしないと、サーバーを乗っ取られるのは時間の問題になってしまうかもしれません。
結果として、AWSは利用するのは簡単ですが、安全に利用するには、ある程度のサーバー運用の知識を必要とすると感じました。これは、AWSがIaaSであるが故、PaaSやSaaSよりもレイヤーが低いことを考えるとやむを得ないことかもしれません。しかし今回は、デモ環境の構築が主目的でしたので、AWS自体の運用・管理に負荷をかけるのは避けたいと考えました。そこで、AWSでのサーバー運用を得意とするテクニカルパートナーに運用を委託することになりました*1。
2.3 国内データセンター
IceWallクラウドデモセンターのもう1つの構成要素に、国内データセンターがあります。これは、デモシナリオにおける「利用者の社内システム」を想定して利用しました。そのため、国内データセンターには仮想サーバーやActive Directoryを用意しました。
AWSと国内データセンターは、VPNで接続されているため、LAN間接続とみなし、AWS上のIDMから国内データセンター内のADを管理する形で利用しています。ADは基本的なドメインユーザーの管理として利用されるだけでなく、後で説明する仮想マシンのプロファイル管理にも利用しています。
それでは具体的な事例として、イントラネット向けのデモについてご紹介したいと思います。
3 イントラネット向けのデモ
イントラネットシステムにおいて、SSOやIDMの導入をご検討されている利用者からいただく要件は、SSOやIDMの標準機能を見てみたい、動作ロジックを理解したい、というものが多いようです。また、ユーザー情報を管理する人事システムとIDM、SSO用の認証DB、ADなどがどのように連携して動作するかにご興味を持たれる方も非常に多いようです。一般的にSSOとIDMが提供する機能は、以下のように分類できるかと思います。
図3:SSOとIDMに求める機能(クリックで拡大) |
このデモでは、これらの標準的な要件をシンプルにご紹介する必要があると考えました。そのため、製品の基本機能でデモを構成し、ソリューション連携をする場合は、疎結合のモデルを採用する方針としました。
SSOには弊社のHP IceWall SSOを、IDMにはエクスジェンネットワークス株式会社のLDAP Managerを使用しました。
3.1 ファーストステップ(SSOとIDMの基本的な連携)
SSOとIDMが連携し動作する基本的なモデルをご紹介するために、以下のようなステップでデモを行います。
図4:SSOとIDMの基本的な連携(クリックで拡大) |
まず社内システムにおけるユーザー情報のマスターが人事DBだとします。人事DBからユーザーの基本情報がCSVファイルで提供され、IDMサーバーが取り込むところからスタートします。IDMサーバーは、内部のマスターDBにユーザー情報を格納する際に、必要な情報の追加やフォーマット変換等をします。その後、プロビジョニング(配信)先の各レポジトリにユーザー情報を配信(DBの直接の更新やファイルの出力)します。
SSO用認証DBは、IDMサーバーにとって、複数あるうちの1つの管理対象DBとするモデル(疎結合)と、IDMサーバー内部のマスターDBと密に連携するモデル(密結合)とがありますが、このデモでは疎結合のモデルをとっています。
このあと、ユーザーはSSO化された社内システムを利用することになります。
- [*1] IceWallクラウドデモセンターの運用・管理は、株式会社クレメンテックにご協力いただいています。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- ForgeRockとの提携やOpenStandiaにみるNRIのオープンソース戦略
- NRI、オープンソースの統合認証・管理ソリューションの新バージョンを提供開始
- 認証データベースへのHBase/Hadoopの適用
- クラウドとの認証連携
- シングルサインオン認証とは ー その種類と仕組み、メリット・デメリットを解説
- 使い勝手、運用管理性、省スペース、ITコスト…VDIの利用で4つの難題を解決する豊島区役所
- オープンソースのシングルサインオンソフトウェア「OpenAM14」リリース
- クラウドネイティブな環境でKeycloakによるシングルサインオンを実現
- グルージェントとソースポッド、 企業向けクラウドセキュリティソリューション分野で協業
- コニカミノルタのワークプレイスハブの詳細が明らかに