最初にTechTargetジャパンが実施した「クラウドインフラに関する読者調査」から、クラウドサービス導入に際しての懸念点のアンケート結果を紹介する。

　パブリッククラウドサービスの利用に当たり、ユーザーはセキュリティや既存システムとの統合管理など、社内コンプライアンス順守に関する懸念点を多く持っていることが分かる。

2．ID管理

　企業内においては、ID管理とアクセス管理を始めとする認証基盤システムの運用が一般的になりつつある。認証基盤システムを導入することにより、複数のリソース（企業内のサーバリソースやさまざまなWebアプリケーション）へ1回のログインで統合的に利用可能となるシングルサインオン（SSO）が可能となり、ユーザーの利便性が向上する。情報システム担当者は個々のID管理の簡易化や、ユーザーの利用状況の把握（証跡）がシステム全体を通して網羅的に可能となり、企業内におけるセキュリティとコンプライアンス順守の助けとなる。

　しかし、ここ数年のパブリッククラウドサービスの普及により、新たなIDとパスワード管理、アクセス管理（多くの場合モバイル端末の普及によるデバイス管理も）をフォローしなければならなくなってきているのは皆さんご存じの通りである。

2－1．クラウドサービス利用によるID管理リスクの増大

　パブリッククラウドサービスでは、多くのアプリケーションが存在し、単一クラウド事業者に閉じた形での利用は少なく、複数のクラウド事業者へのID登録（＝管理）が必要となる場合が多い。セキュリティの観点からすると、ユーザーにはクラウドサービスごとに異なるID／パスワードを利用してもらいたいところだが、現実的な運用方法とは言い難く、結果としてパスワードの使い回しが発生し、潜在的セキュリティリスクにつながる恐れがある。

　このようなリスクを避けるためにも、企業内の認証基盤システムによるSSOをパブリッククラウドサービスに適用したいというニーズの発生は自然な流れといえる。

　多くのパブリッククラウドサービスは、さまざまなネットワーク環境からのアクセスを前提としており、外部（この場合は企業内）の認証基盤システムとの連係には何らかの仕組みが必要となる。今後のハイブリッドクラウドの利用において、企業内の認証基盤システムとのID連係機能の有無はパブリッククラウドサービスを選定する要素の1つとして考慮した方がよい。

2－2．認証基盤システムの連係の仕組み

　パブリッククラウドサービスと認証基盤システムのID連係機能は、一般的に「フェデレーション」と呼ばれる。利用するパブリッククラウドサービスをSP（Service Provider）と呼び、フェデレーション機能を提供するサーバもしくはサービスをIdP（Identity Provider）と呼ぶ。

　SPには信頼するIdP情報をあらかじめ登録する必要がある。登録の方法や形式はSPごとに異なるが、基本的には管理者による手動設定である。また、SPとIdP間でやりとりする属性情報の種類もSPによって異なる。しかし共通の動作としてSPとIdP間にパスワードを含む認証情報が流れないことは注目したい。ネットワークを通じてやりとりがなされるのは、トークンやアサーションと呼ばれる「誰に何を許可するか？」という属性情報であり、それによりパスワード漏えいに関する一定の安全性を確保している。

　図3にあるSPとIdP間の連係の技術仕様はオープンな標準化された仕様である。関連する主な仕様を以下に紹介する。

↓OpenIDファウンデーション・ジャパン公開資料より一部抜粋、再レイアウト

　将来的に「OpenID Connect」に収れんしそうな流れはあるが、現時点では複数の仕様をサポートするSPとIdPが多い。認証基盤システムにおいてフェデレーション機能を利用する場合には、必ず仕様のチェックと事前テストをなされたい。

2－3．プライベートクラウドでのID管理

　プライベートクラウドにおけるID管理では、基本的に信頼できるネットワーク内での処理となるため、直接的に認証基盤システムとの連係を考えるのが最もシンプルである。

　プライベートクラウドを構成するクラウドOS（「OpenStack」や「VMware vSphere」など）の認証機能の多くは既存の認証基盤システムとの連係機能を持っている。例えばOpenStackでは、以下のバックエンド認証との連係機能を持つ。

• メモリ内のキーバリュー型ストア（シンプルな内部ストレージ構造）
• SQLデータベース（MySQLやPostgreSQLなど）
• PAM（Pluggable Authentication Module）
• LDAP（OpenLDAPやMicrosoftのActive Directory）

　OpenStackではID管理を「Keystone」と呼ばれるコンポーネントが担当している。このKeystoneのプラグインの形でバックエンド認証との連係の仕組みが提供されている。OpenStackではIceHouseリリースでKeystoneにおけるバックエンド認証システム連係が強化されているので、それ以降のリリースを利用すれば安定した運用が期待できるだろう。

　パブリッククラウドサービスと同様に、フェデレーション機能によるID連係も可能である。この場合、対象となる企業内のプライベートクラウドがSPとなる。OpenStackの場合、KeystoneはJunoリリースでSAML（Security Assertion Markup Language）とOpenIDをサポートしている。また最新のKiloリリースでは、OpenID ConnectのサポートやIdPとしての機能も実装されている。

　このように、ハイブリッドクラウドにおけるセキュリティとコンプライアンス管理は、ID管理を基礎として、既存の認証基盤システムとの連係を進めることでシンプルかつ統合的に維持することができる。

　パブリッククラウドであれば、フェデレーション機能を利用した認証基盤システムとの連係（特に互換性と実績）を、プライベートクラウドであれば、その基礎となるクラウドOSの認証機能がサポートするID統合やID連係機能の種類と方法をチェックし、ハイブリッドクラウドを構成する際のデザイン基準の1つとされたい。

3．新しいセキュリティポリシーの配置方法

　ここまで、ハイブリッドクラウド利用におけるセキュリティとコンプライアンス管理の基礎となるID管理に関して述べてきた。ここで少し視点を変えて、クラウド時代の新しいセキュリティポリシーの運用について触れてみたい。

　現状、社内ITにおけるセキュリティ管理は、管理セグメントを「トラステッド」「アントラステッド」に分けて（セグメンテーション）、その境界線をファイアウォールやIDS（侵入検知システム）／IPS（侵入防止システム）で保護するのが一般的な方法である。クラウドの利用においても基本的な考え方は同様だ。しかし、クラウドの基礎技術である仮想化技術によって、セキュリティの境界線の細分化が進んでいる。

3－1．分散ファイアウォールとマイクロセグメンテーション

　簡単に言うと、これまでセグメントの境界線にいたファイアウォールをより細分化して、よりアプリケーションの近くに配置しようという考え方である。これによりファイアウォールによって保護されるセグメントも細分化され、より細かいセキュリティコントロールが可能となる。

　また仮想マシン間においては、従来の境界線上のファイアウォールを通らない通信が多く発生する。これまでの仕組みではそのトラフィックのセキュリティを管理することは困難であったが、ファイアウォールが分散されることによってそれも可能となる。

3－2．ハイブリッドクラウドでの利用

　ファイアウォールの分散配置によるマイクロセグメンテーションでは、ファイアウォール機能とセキュリティポリシーを管理、制御するコントロール機能は分離される。この“Software Defined Network”的な考え方により、システム全体でのセキュリティポリシーの管理とポリシーの一括配布が可能となる。これまでもiptables、Windowsファイアウォールなど、OS機能を利用してファイアウォールを分散化する方法は存在したが、システム全体で統合的にセキュリティポリシーの管理を行うのは手間の掛かる作業だった。

　ハイブリッドクラウドでの利用に当たっては、パブリッククラウドとプライベートクラウドの両方に分散するファイアウォールを透過的に管理可能な製品を検討すべきである。またファイアウォール機能とコントロール機能間では、通信遅延の極小化が求められるため、物理的なダイレクト接続形態を構成するのがよい。パブリッククラウドサービスの多くはダイレクト接続サービスを持っているので、それを利用するのが望ましい。

4．参考になるセキュリティ規定、ガイドライン

　最後に、ハイブリッドクラウドをデザインする際に参考となる各種のセキュリティ関連の規定やガイドラインを紹介する。

4－1．「クラウドの安全性・信頼性」を示すガイドライン、参考資料