モデル駆動型クラウド・セキュリティー

クラウド・アプリケーション・セキュリティー・ポリシー・オートメーションを導入してクラウドのセキュリティーを高める

セキュリティー・ポリシーを技術実装へと手動で変換するのは、難しくてコストがかかり、エラーが起こりやすい作業ですが、これをアプリケーション層で実装する場合は尚更のことです。実装にかかる時間と資金をより削減するには、クラウド・セキュリティー・ツールの自動化を進める必要があります。クラウド・セキュリティー・ツールの自動化は、クラウド管理者がより重要なセキュリティー問題に専念できるようにクラウドのセキュリティー管理を簡易化する上でも欠かせません。

この記事では、効果的なアプリケーション・セキュリティー・ポリシー・オートメーションを実現する上での課題を詳しく説明し、モデル駆動型セキュリティーがセキュリティー・ポリシー・オートメーションにもたらすメリットを解説した後、クラウド・アプリケーション・セキュリティー・ポリシー・オートメーションを実現する方法を紹介します。

Ulrich Lang, CEO, Object Security

Ulrich Lang photoDr. Ulrich Lang は、ObjectSecurity の共同設立者兼 CEO です。ObjectSecurity の OpenPMF 製品はオートメーションによってアプリケーション・セキュリティーを管理しやすくします。モデル駆動型セキュリティー、セキュリティー・ポリシー、クラウド/SOA/ミドルウェア/アプリケーション・セキュリティーにおける名高い思想的指導者、著者、講演者である空は、情報セキュリティーの分野で 15 年を超える経験を積んでいます。彼は 1997年にロイヤル・ハロウェイ・カレッジ (ロンドン大学) で優秀な成績でコンピューター・サイエンスの修士号を取得した後、2003年にケンブリッジ大学コンピューター・ラボ (セキュリティー・グループ) から、ミドルウェア・セキュリティーの概念的見地側面での博士号を授与されました。



2011年 2月 08日

クラウドの導入には、セキュリティーが不可欠です。セキュリティーの欠如が、クラウド導入の致命的な問題となる場合はよくあります。けれども、セキュリティー・ポリシーおよびコンプライアンスの複雑さが増し、IT がより複雑でアジャイルなものになっているなか、セキュリティー・ポリシーをセキュリティー実装に変換する作業は、これまでよりも時間がかかり、反復的でコストが高く、エラーを起こしやすいものになっています。そのため、エンド・ユーザーの組織にとって膨大な作業になりがちです。そんなエンド・ユーザー組織 (およびクラウド・プロバイダー) の作業を減らし、ポリシー実装の正確性を高めるには、オートメーションが効果を発揮します。この記事では、とりわけ興味深く、やりがいがありながらも、忘れられがちな話題に焦点を当てます。それは、アプリケーション層のセキュリティー・ポリシー・オートメーションです。

クラウド・アプリケーション・セキュリティー・オートメーション

アプリケーション・セキュリティー・ポリシー・オートメーションとは、企業のセキュリティー・ポリシーやコンプライアンス規則、ベスト・プラクティスといった人間が理解できるセキュリティー要件を、それに対応してアプリケーション層で実施される技術的なセキュリティー・ポリシーのルールおよび構成に変換することです。アプリケーション・セキュリティー・ポリシー・オートメーションには、その一環として監査のオートメーションも含まれます。例えばセキュリティー態勢を継続的に評価するために、アプリケーション層のアラートを収集し、これらのアラートを人間が理解できるセキュリティーおよびコンプライアンスの要件へと逆に対応させるなどです。

クラウド・アプリケーション・セキュリティー・ポリシーの分析

アプリケーションが相互に接続され、その環境が動的に変化するサービス指向アーキテクチャー (SOA) やクラウド・アプリケーション・マッシュアップ、そしてその他の「プラグ・アンド・プレイ」のアプリケーション環境では、アプリケーション・セキュリティー・ポリシーがかなり複雑になりがちです。このようなアプリケーション環境はさまざまなビジネス上の理由から採用されているため、セキュリティーもこれらの理由に対応していなければなりません。しかも、全体的な保守作業は最小限にしなければなりません。その鍵となるのが、オートメーションです。

セキュリティー・オートメーションは、クラウド・コンピューティングでは特に重要になってきます。クラウド・ユーザーは法規制を遵守するためのポリシー管理のサポートをクラウド・プロバイダーに求めますが、それと同時に、そのメリットをクラウド・コンピューティング全般に対する判断基準と同じ基準で判断するためです (つまり、先行投資および社内の手動による保守作業をどれだけ削減できるかによって判断します)。

一般に、「アプリケーション層のセキュリティー」はこの記事で取り上げるポリシー・オートメーションの側面よりも遥かに広範囲に及ぶものであり、脆弱性のスキャン、アプリケーション層のファイアウォール、構成管理、アラートの監視と分析、ソース・コードの分析などのタスクも含まれます。アプリケーション層のセキュリティー・ポリシーにとりわけ大きく関係するタスクは、ID およびアクセスの管理です。ID およびアクセスの管理は、アプリケーションのセキュリティーというよりは、ユーザー ID の管理に関するタスクだと思われがちですが、実際のところ、ほとんどの場合はアプリケーション層のセキュリティーに密接に関連します。ユーザーがアプリケーションにアクセスして、その認証が行われるときには、承認ポリシーを実施しなければなりませんが、この承認ポリシーはアクセス対象のアプリケーションによってかなり異なってくるためです。

そこで浮上してくるのが、この承認ポリシーをどこから提供するのか、誰が作成して管理するのか、どのように実施し、どのように監査するのかという難問です。それと同時に、これらの問題が、アプリケーション・セキュリティー・ポリシー・オートメーションを採用する理由となります。ID およびアクセスの管理と併せてアプリケーション・セキュリティー・ポリシー・オートメーションを使用することで、ポリシー管理にかかる時間、繰り返しの作業、コスト、そして発生するエラーが減ってきます。

クラウド・アプリケーション・セキュリティー・ポリシー・オートメーションの現状の導入状況

クラウドでは尚更のこと、セキュリティー・ポリシー・オートメーションは全般的に、比較的初期の段階にあるため、ほとんどの場合その焦点の中心となるのは、「サービスとしての ID/認証」です (例えば、Facebook の接続など)。一方、クラウドをベースとするセキュリティー・サービスもいくつかあり (ウィルス対策、E メール・スキャン、侵入検知システム (IDS)、ログ管理)、そのなかには間接的にアプリケーションに関連しているサービスもあります。

この記事で焦点とする、「サービスとしてのアプリケーション・セキュリティー・ポリシー・オートメーション」は、今のところはまだ、数少ない先駆者が導入しているにすぎません。その一例は、ObjectSecurity です。ObjectSecurity の OpenPMF モデル駆動型セキュリティー・ポリシー・オートメーション製品には、PaaS (Platform as a Service) タイプのプライベート・クラウド (Intalio BPMS を使用した Intalio Cloud) が統合され、クラウド・マッシュアップのシームレスなポリシー・オートメーションを実現しています。OpenPMF を使用した初期段階のセキュリティー・ポリシー・オートメーションには、米海軍用のものもあります。これはプライベート・クラウドと SOA のどちらに位置付けるか判断しにくく、高度に保証された環境に、仮想 IT サービスを対象とした「サービスとしてのポリシー」を取り込んでいます。「事例研究」のセクションでは、この 2 つの事例について検討します。

モデル駆動型セキュリティー・ポリシー・オートメーションの導入事例は他にいくつもありますが、いずれもクラウドを対象としたものではなく、そのほとんどは、サービスとしてのポリシーを取り込んでいません。


アプリケーション・セキュリティー・ポリシー・オートメーションの課題

残念ながら、セキュリティー・ポリシー・オートメーションは口で言うほど簡単には行かないのが通常です。このセクションでは、アプリケーション・セキュリティー・ポリシー・オートメーションの実現を難しくしている理由を概説します。

人々と組織にとってポリシーが大きな意味を持ってくるにつれ、その実装およびオートメーションは難しくなってきます

最近のセキュリティー・ツールの多くは、ある程度のオートメーション (メンテナンス・フリー) を実現していますが、オートメーションと引き換えに、関連性と正確さが犠牲にされています。具体的には、エンド・ユーザー組織がどのようなデフォルト・セキュリティー・ポリシーを実装する必要があるかを、ベンダーが認識しているという前提のもとでツールが自動化されている場合もあれば、試行錯誤によってポリシーを学ぶように製品が作られている場合もあります。この両方の手法に共通する欠点は、セキュリティー・メカニズム自体は機能するとしても、意図されないポリシー、関連性のないポリシー、あるいは不完全なポリシーを実装する可能性があることです。

このような従来のセキュリティー・オートメーションは、汎用のセキュリティー・ツールには比較的有効に機能します。これに該当するセキュリティー・ツールは、組織固有のポリシーを必要とせず、技術スタックの下位層 (ネットワーク層やオペレーティング・システム層など) をターゲットとする、ウィルス対策、マルウェア対策、事前構成されたネットワーク侵入検知システム、汎用アプリケーション脆弱性スキャンなどのセキュリティー・ツールです。

組織、ユーザー、およびアプリケーションの振る舞いを考慮してセキュリティー・ポリシーを実施および監査しなければならない場合には、セキュリティー・オートメーションの難易度は高くなります。例えば、クレジット・カードによる支払処理を行う組織では、「組織の外部では、クレジット・カード情報は必ず暗号化すること」というポリシーや、「使用されなくなったクレジット・カード情報は削除すること」というポリシーを実装しなければなりません。別の例としては、医療関係の組織も挙げられます。医療関係の組織では、「医師と看護師がアクセスできるのは、現在担当している患者の医療記録に限られること、そして正当な目的がある場合にのみ、アラーム監査ログを作成せずにアクセスを認めること」といったポリシーを実装する必要がある場合もあります。このように複雑かつコンテキストに即したポリシーは、特定の組織のセキュリティー・ポリシー、ビジネス・プロセス、アプリケーション、そしてアプリケーション間の相互作用に依存します。そしてエンド・ユーザー組織がこのようなポリシーを実装する理由が、業界特有の規制 (PCI DSS (PCI Data Security Standard)、HIPAA (Health Insurance Portability and Accountability Act)) を満たすためであることも珍しくありません。

ポリシーの数が増え、複雑で内容が豊富になり、きめ細かく、コンテキストがより深く関わってくるにつれ、その実装およびオートメーションは難しくなってきます

最近では ID およびアクセスの管理に分類されることも多い、従来の「承認管理」が明らかにしている難題は、システムおよび参加者が多数に及び、相互接続されたアプリケーションが動的に展開し (「アジリティー」を持ち)、さらにはポリシーの内容が豊富で、詳細にわたって記述され、コンテキストに依存するようになった場合には、ポリシーの管理が手に負えなくなることです。

管理するにはあまりにも多く、あまりにも複雑な、技術的なセキュリティー・ルールがあるというだけで、承認ポリシーを明確に指定することも、管理することもできなくなり、実施中のポリシーに対する信頼が損なわれることがあります。前述のとおり、答えを出さなければならない問題は、この承認ポリシーをどこから提供するのか、誰が作成して管理するのか、そしてどのように実施し、どのように監査するのかという点です。

IT 全体がよりアジャイルに相互接続されるようになるにつれ、ポリシーのオートメーションは困難になります (特にクラウド・マッシュアップの場合)

クラウドや SOA などのアジャイルなアプリケーション環境の背後にある導入理由をサポートするためには、承認管理自体がその環境以上にアジャイルであるとともに、自動化されて管理しやすく、細分度が高く、コンテキストに依存していなければなりません。残念ながら、一貫性のある的確な技術的なセキュリティー・ポリシーを作成して管理するのは、頻繁かつ動的に変更されるシステムでは、かなりの難問となります。その理由は、動的変更 (例えば、クラウド・マッシュアップの動的変更) によって、実装された技術的なポリシーが無効になる可能性があるためであり、さらにはアプリケーションが相互に接続され、その環境が動的に変化する SOA やクラウド・アプリケーション・マッシュアップ、そしてその他の「プラグ・アンド・プレイ」のアプリケーション環境では、アプリケーション・セキュリティー・ポリシーが非常に複雑になりがちであるためです。このような難しさはあるとは言え、それでもやはり、アプリケーション承認ポリシーをすべての保護されたリソースに対して実施し、監査するには、承認管理は欠かせない技術構成ブロックです。クラウド・アプリケーション・セキュリティーに不可欠な役割を果たす承認管理は、クラウド・マッシュアップとなると、その重要性がさらに大きくなります。それは、異なる複数のアクター (ユーザーまたはクラウド・アプリケーション) が互いのサービスを呼び出せるのは、特定の状況でセキュリティー・ポリシーに基づいてその呼び出しが承認される場合に限られるからです。重要な承認管理標準には、OASIS の XACML (eXtensible Access Control Markup Language) があります。

法規制の遵守はポリシーに関連する要件であるため、可能な限り自動化されたサポートも必要になります

エンタープライズ・クラウドのユーザーが、クラウドがホストするアプリケーションおよびサービスに対する容易で保守作業の少ない (自動化された) コンプライアンスのサポートを要求するのは当然のことです。というのも、多くのクラウド・アプリケーションは、監査の必要がある規制された情報 (プライバシー、医療情報、支払情報) を扱うことになりますが、これらの情報が組織の境界をまたがることはよくあることだからです。クラウド・スタックに対するクラウド・ユーザーの可視性は限られることから (これは特に、PaaS および SaaS の場合に言えることですが、IaaS も例外ではありません)、コンプライアンス監査はクラウド・ユーザーだけの責任にすることはできません。そのため、(セキュリティー管理とインシデント監視と同じく) ある程度の法規制の遵守をクラウド・プラットフォームに組み込む必要があります。

ブラックリスト方式ではもはや必要を満たさないため、ホワイトリスト方式に基づくポリシーが必要となります

念のために言っておくと、ブラックリスト方式とは、ブラックリストに載っていないユーザーにアクセスを許可することを意味します。ホワイトリスト方式とは、ホワイトリストに載っているユーザーにのみアクセスを許可することです。


モデル駆動型セキュリティー・コンポーネント

オートメーションを実現するには、何らかの「アルゴリズム」が、セキュリティー・ポリシーの要件と、そのポリシーが関連するすべての要素 (ユーザー、アプリケーション、アプリケーションの相互接続、アプリケーションのワークフロー) を正しく反映し、対応する技術的なセキュリティー・ポリシー実装を自動的に生成することが可能でなければなりません。モデル駆動型セキュリティーは、この要求されるレベルのセキュリティー・ポリシー・オートメーションを実現しやすくする手段として、モデル駆動型ソフトウェア開発手法の背後にある論法をセキュリティー・ポリシーおよびコンプライアンス・ポリシーの管理に適用します。

モデル駆動型セキュリティー

基本的に、モデル駆動型セキュリティーでは、アプリケーションとそのすべての相互作用を分析し、汎用セキュリティー要件をその分析結果に適用することで、技術的な承認ルール (およびその他のルール) を自動的に生成することができます。モデル駆動型セキュリティーは、ツールによってサポートされるプロセスです。このプロセスでは、セキュリティー要件のモデル化を抽象化レベルの上位で行い、その他のシステム関連の情報ソース ((他の利害関係者によって作成された) アプリケーションの機能モデルなど) を使用して、コンテキストに依存した細分度の高い技術的な承認ルール (およびその他のルール) を自動的に生成します。モデル駆動型セキュリティーへの入力は、汎用モデリング言語 (統一モデリング言語 (UML) など) または EA (Enterprise Architecture) フレームワーク (DODAF (Department of Defense Architecture Framework)、MODAF (Ministry of Defense Architecture Framework)、NAF (NATO Architecture Framework) など) を使用して、DSL (Domain Specific Languages) で表現されます。

セキュリティー要件の収集は、グラフィカル・エディターを使用して行わなければならないわけではありません。テキスト・モデル・エディター (例えば、Eclipse などのモデリング・ツール) を使用して収集することもできます。収集したセキュリティー要件は、アプリケーションとそのすべての相互作用に関する情報を分析することによって、実施可能なセキュリティー・ルール (アクセス制御および監視ルール) に自動的に変換されます。

モデル駆動型セキュリティー・ランタイムは、保護対象とするすべての IT アプリケーションでのセキュリティー・ポリシーの実施、自動ポリシー更新、およびポリシー違反の総合監視を実行時にサポートします。モデル駆動型セキュリティーの最初のステップでは、モデル駆動型セキュリティー・ツールで、規制およびガバナンス標準が上位レベルのセキュリティー・ポリシーとしてモデル化 (または事前に作成されたテンプレートから選択) されます。このセキュリティー・ポリシー・モデルを構成システムの機能モデルに適用するために、セキュリティー・ポリシー・モデルのアクターをシステム・アクターにマッピングし、これらのシステム・アクターの振る舞いをセキュリティー・ポリシー・モデルに従って制約します。

技術的な観点から見ると、これらの (セキュリティーおよび機能) モデルは、細分度が高くてコンテキストに依存した下位レベルのセキュリティー・ポリシーへと自動的に変換されて、クラウド・オーケストレーション、クラウド・マッシュアップ、あるいは SOA 環境全体で (例えば、ミドルウェアに統合されたローカル実施ポイントを介して、あるいはドメイン境界で) 実施されます。ローカル実施ポイントは、セキュリティー・コンプライアンス関連のイベントの監視にも対処します。これで、SOA アプリケーション (またはその相互作用構成) が変更されるたびに、モデル駆動型セキュリティーがセキュリティーの実施および監視を自動的に更新することが可能になります。

要するに、モデル駆動型セキュリティー・プロセスは、ポリシーのモデル化、ポリシーの自動生成、ポリシーの実施、ポリシーの監査、そして自動更新というステップに分けられます。記事では、これらのステップのそれぞれがクラウド・アプリケーションのコンテキストでどのように機能するのかを検討します。

モデル駆動型セキュリティーのアーキテクチャー

図 1 に、基本アーキテクチャーを示します。左上に示されているのは、クラウド・ベースの開発およびマッシュアップ環境 (BPMS (Business Process Management System) によって作り上げられた Web サービス) です。ここには、ポリシー生成を自動化するために開発/マッシュアップ・ツール・チェーンに (クラウド・プロバイダーが) インストールする必要があるモデル駆動型セキュリティーの構成要素も示されています。

右上には、一般形式で定期的にポリシーを更新する開発ツールに対するモデル駆動型セキュリティー・アドオンを、PaaS に対して提供するクラウド・セキュリティー・サービス、そしてこのクラウド・セキュリティー・サービスが提供するランタイム管理 (監視/分析/レポート作成) 機能が示されています。

図の下部には、アプリケーション・サーバーにデプロイされた複数のクラウド・サービス (およびクラウド・ランタイム・スタックの残り) が示されています。これらのサービスのポリシー実施 (PEP) + 監視ポイントは、ランタイム・スタックと併せて (クラウド・プロバイダーが) インストールする必要があります。

アプリケーションが開発されて統合される際に、モデル駆動型セキュリティーは自動的にそのアプリケーションとポリシー・モデルを分析し、関連する PEP/監視ポイントに自動的に組み込まれる技術的なルールを生成します。保護対象サービスの間でメッセージが渡されるときには、必ずモデル駆動型セキュリティーが自動的に技術的なポリシーを評価して実施し、必要に応じて、インシデント・アラートをクラウド・セキュリティー・サービスのランタイム・セキュリティー・ポリシー管理機能に送信します。

図 1. アーキテクチャーの概略図: PaaS 型クラウドを使用したモデル駆動型セキュリティー・ポリシー・オートメーション
アーキテクチャーの概略図: PaaS 型クラウドを使用したモデル駆動型セキュリティー・ポリシー・オートメーション

利点

効果的に導入されたモデル駆動型セキュリティー (「事例研究」を参照) には、多くの利点があります。

  • アジャイルなソフトウェア・アプリケーションの場合には尚更のこと、オートメーション (ポリシーの生成、実施、監視、更新) によって手動による管理作業のオーバーヘッドが減り、コストと時間を節約することができます。
  • 人間がエラーを起こす可能性を最小限に抑え、セキュリティー実装が常にシステムのビジネス要件および機能の振る舞いと一致するようにすることで、セキュリティーのリスクを減らし、信頼性を高めます。その結果、システムのセキュリティーと安全性の両方が強化されることにもなります。
  • さらに、セキュリティー・サイロ (例えば、異なるアプリケーション・ランタイム・プラットフォーム) 全体で常にポリシーが統一されます。
  • 最後の利点として、より自動化されたモデル駆動型のアジャイルな認定手法の一部となります。

欠点

モデル駆動型セキュリティーの導入は、以下をはじめとするいくつかの理由によって難しくなる場合があります。

  • アプリケーションの仕様、そしてかなり明確に定義された SDLC (Software Development Life Cycle) への依存。ただし、相互接続されたシステムの側面 (特に、クラウド・マッシュアップの相互作用) をモデル化することが、最先端のクラウド PaaS およびマッシュアップには重要な部分であり、堅牢なシステム設計の一環でもあります。
  • システムとセキュリティー・ポリシーをモデル化する作業。そうは言っても、適切な粒度でシステムをモデル化することが (例えば、クラウド・マッシュアップ・モデルなど)、実際にポリシー管理の総コストを加算させることにはなりません。というのも、セキュリティー管理者が、手持ちのツールがモデル駆動型セキュリティーをサポートしていないという理由で、技術面での詳細なセキュリティー・ルールを手動で指定しなければならないとしたら、実質的にはポリシー管理ツールでアプリケーション仕様のセキュリティーに関連する側面を指定していることになりますが、実際のところ、平凡ではないシステムのセキュリティー関連の側面をポリシー管理ツールで指定することはできません。特に、システムのライフサイクル全体を対象として指定するとなれば、尚のこと不可能な話です。モデル駆動型セキュリティーは、こうした情報 (大抵は、セキュリティー・ポリシー・ルールの大部分を占める情報) を、アプリケーションとワークフローをよく理解しているスペシャリスト (つまり、アプリケーション開発者/インテグレーターとプロセス・モデラー) やツールによって指定されたモデルから再利用します。

実際の経験では、モデル駆動型セキュリティーは、わずかな期間運用しただけでも、従来の手動によるポリシーの定義および管理に比べ、システムを保護するための作業コストが大幅に削減され、セキュリティーと安全性が大幅に強化されます。


クラウド・アプリケーション・セキュリティー・ポリシー・オートメーションの実現

クラウド PaaS の登場により、上述のモデル駆動型セキュリティー・アーキテクチャーのすべて、あるいは部分的にでもクラウドに移し、最大限のオートメーションでクラウド・アプリケーションおよびマッシュアップを保護し、監査することが当然のこととなっています。具体的には、セキュリティー・ポリシー・モデルをクラウド・サービス (サービスとしてのポリシー) としてアプリケーション開発およびデプロイメント・ツールに提供し、ポリシー・オートメーションをクラウド・アプリケーションのデプロイメントおよびランタイム・プラットフォームに組み込むということです (自動化されたポリシーの生成/更新、実施、監視)。

クラウド・デプロイメントには、さまざまなシナリオが考えられます。例えば、開発ツールとアプリケーション・プラットフォームのセキュリティー機能のすべてを PaaS プロビジョニングの一部として同じクラウド・サービスでホストするという場合もあれば、セキュリティー機能のうちのいくつか (特にポリシーの構成と監視) を分離してホストするという場合もあります。これが、ローカルの非クラウド・デプロイメントとは異なる点です。通常、ローカルの非クラウド・デプロイメントでは、多数のローカル・ランタイム・アプリケーション・プラットフォーム (Web アプリケーション・サーバーなど) 上のアプリケーションを保護し、ローカルの監視およびレポート作成をサポートするために、ローカルにインストールされた開発ツール (Eclipse など) の内部、またはこれと併せてモデル駆動型セキュリティーがインストールされます。

前述のとおり、通常のモデル駆動型セキュリティー・プロセスは、ポリシーのモデル化、ポリシーの自動生成、ポリシーの実施、ポリシーの監査、そして自動更新というステップに分けられます。ここからは、これらのステップのそれぞれがクラウド・アプリケーションのコンテキストでどのように機能するのかを調べることにします。以降のセクションでは、モデル駆動型セキュリティーの 5 つのステップについて、クラウドのコンテキストで説明します。

クラウドでのポリシーの構成 (サービスとしてのポリシー)

モデル駆動型セキュリティーのクラウド版では、ポリシー構成を購読ベースのクラウド・サービスとしてアプリケーション開発ツールに提供することができます。ポリシー・モデルの仕様、保守、および更新がクラウド・サービスとしてアプリケーション開発者とセキュリティー・エキスパートに提供されることには、大きなメリットがあります。そのうち最も重要なメリットは、モデル駆動型セキュリティーに使用するポリシー・モデルを指定 (または購入してインストール) して継続的に保守する必要がなくなることです。したがって、アプリケーション開発者とセキュリティー・スペシャリストがモデルの詳細を調べる必要がなくなり、必要な種類のポリシー・フィードを購読するだけで済むようになります。

ポリシーのモデル化、保守、更新は、サービスとしてのポリシーのプロバイダー (通常は、クラウド・プロバイダーとは異なるプロバイダー) が引き受けてくれます。メリットはそれだけではありません。最新のポリシー・モデルが継続的にフィードとして提供されるため、ユーザー組織がセキュリティーとコンプライアンスのエキスパートになる必要がないというメリットもあります。さらに、購読モデルのおかげで先行投資のハードルが最小になること、そしてエンド・ユーザー組織が規制とベスト・プラクティスに変更があるかどうかを常に監視する必要がないこともメリットとして挙げられます。

複雑なポリシーには、単純なセットアップと、場合によってはセキュリティー関連の情報へのタグ付けが必要になってくることがあります。PCI DSS ポリシー・モデルの購読を例にすると、アプリケーション・マッシュアップ・モデルだけでなく、支払情報関連のインターフェースにもタグを付ける必要があります。クラウドに統合されたパッケージ済みクラウド・モジュールの数が多ければ多いほど、クラウド・プロバイダーがすでにクラウド・モジュールにタグを付けている可能性があるため (例えば、支払処理モジュールには PCI 関連のタグが付けられているなど)、エンド・ユーザー組織がタグ付けを要求されることは少なくなります。

一般に、上述のアウトソーシング・モデルは新しいものではありません。これまで何年もの間、セキュリティーの他の側面 (ウィルス対策やスパイウェア駆除) では有効に利用されてきました。ユーザーはウィルス対策プロバイダーからのポリシー・フィードを購読し、ウィルス対策ソフトウェア・クライアントに自動的にそのポリシーを実施させればよいのです (ただし、この記事で説明するのはウィルス対策のアウトソーシング・モデルではなく、クラウド・アプリケーションのセキュリティーに適用されるアウトソーシング・モデルです)。

クラウド・ベースの承認ポリシー管理サービスの信頼性と確実性を要求するのは当然のことですが (特にミッション・クリティカルな環境の場合)、そのようなデプロイメント・シナリオに含まれる意味は、保護対象のクラウド・アプリケーションに本来備わっている信頼性および確実性との関連で捉えなければなりません。保護対象のクラウド・サービスそのものにインターネットでアクセスできるとしたら、ポリシー管理サービスへの多くの攻撃 (DoS 攻撃など) がその保護対象のサービス自体に向けられる可能性もあります。この場合、クラウド・ベースのポリシー・マネージャーがそのリクスを増大させることはありません。さらに高い信頼性および確実性が必要な場合 (例えば QoS (Quality of Service) が有効にされたプライベート・クラウドの場合) には、ポリシー・マネージャーと保護対象のサービスの両方に、強化したインフラストラクチャーが必要になってくるでしょう。要するに、クラウド・ベースのセキュリティー・ポリシー管理は、すべてとは言わないまでも、多くの組織を対象にプロビジョニングされた大多数のサービスにとって適切な選択肢になるということです。

クラウドでの技術的なポリシーの自動生成

モデル駆動型セキュリティーのポリシー自動生成機能は、開発ツール、デプロイメント・ツール、マッシュアップ・ツールに組み込まれ (機能的なアプリケーション情報にアクセスするため)、前のセクションで説明したポリシー・フィードを使用します。PaaS には、クラウドでホストされた開発およびマッシュアップ・ツールとランタイム・アプリケーション・プラットフォームが含まれていることがあります。その場合、モデル駆動型セキュリティーを利用した技術的なポリシーの自動生成もクラウドに移し、クラウドでホストされた開発、デプロイメント、マッシュアップのプロセス中にアプリケーションに応じて自動的に技術的なセキュリティー・ポリシーを生成することもできます。これは特にマッシュアップ・ツールの場合に当てはまります。マッシュアップ・ツールはクラウドでホストされる可能性が高く、大抵はグラフィカル・ツールやモデル駆動型ツールになっていて、クラウド・サービス間のやりとりと情報フローに関係しているためです。開発ツールが PaaS クラウドでホストされていない場合には、モデル駆動型セキュリティーの技術的なポリシーの自動生成機能をローカル開発ツールに統合する必要があります。

クラウドでのセキュリティー・ポリシーの自動実施

クラウド・サービスへのアクセスが行われるときに、必ず自動生成された技術的なポリシーが実施されるようにするには、当然、ポリシーの実施を PaaS アプリケーション・プラットフォームに統合しなければなりません。前のセクションで説明したように、ポリシーはホストされたモデル駆動型セキュリティーと PaaS 開発ツールを使用してクラウド内で生成されることもあれば、ローカルのモデル駆動型セキュリティーおよび開発ツールからアップロードされることもあります。

ポリシー実施ポイントがどのように PaaS アプリケーション・プラットフォームに組み込まれるかは、PaaS アプリケーション・プラットフォームがポリシー実施ポイントのインストールを許可するかどうか (例えば、各種のオープンソース PaaS プラットフォームでは許可。「事例研究」を参照)、PaaS アプリケーション・プラットフォームでサポートするポリシー実施ポイントが標準ベースであるか (例えば、OASIS XACML)、それとも独自仕様であるかによって決まります。

クラウドでの自動ポリシー監視

一般にポリシー実施ポイントは、ブロックされた呼び出しに関連するインシデントについてのアラートをはじめ、セキュリティー関連のランタイム・アラートを発生します。これらのアラートの収集、分析、視覚表示についても、同じくクラウドに移すことができます。こうすることによるメリットにはさまざまなものがあります。例えば、複数のクラウド・サービスのインシデントを他の情報 (ネットワーク侵入検知など) と併せてまとめて 1 箇所で分析することができます。また、複数のクラウド・サービスのセキュリティー態勢を統合して視覚表示すること、統合したインシデント情報を監査のために保管すること、そしてコンプライアンス関連の決定サポート・ツールをクラウド・サービスとして提供することもできるようになります。

自動更新

アプリケーションが変更されたとき (特にその相互作用が変更されたとき) には常に、ここで説明するモデル駆動型手法によって、技術的なセキュリティー・ポリシーの実施と監査を自動更新できるようになります。これと同じオートメーションは、セキュリティー要件が変更された場合にも実現可能です。

エンド・ユーザー組織とクラウド・プロバイダーがセキュリティー・ポリシー・オートメーションを使用する方法

これまで説明してきたサービスとしてのポリシーという手法は、以下に示すようにエンド・ユーザー組織の負担だけでなく、クラウド・プロバイダーの負担も大幅に軽減します。

  • エンド・ユーザー組織のセキュリティー専門家が行わなければならない作業は、クラウド・プロバイダーが提供するクラウドの利用をセキュリティー・オプションに指定して、サービスとしてのポリシーを購読すること、場合によっては単純なセキュリティー・タグ付け機能 (または開発者の教育) を導入すること、そしてコンプライアンス・レポートを定期的にチェックすることだけです。ただし、それにはまず、セキュリティー専門家の重要な仕事としてクラウド・プロバイダーにポリシー・オートメーションを要求しなければなりません (特に、プライベート・クラウドの場合)。
  • エンド・ユーザー組織のアプリケーション開発者/インテグレーターが行わなければならない作業は、クラウド・プロバイダーから提供される、サービスとしてのポリシーで機能強化されたマッシュアップ/開発ツールを使用すること、そして場合によっては単純なセキュリティー・タグ付け機能を導入することだけです。
  • PaaS クラウド・プロバイダーがエンド・ユーザー組織に対してこうした作業の単純化をすべて実現するには、ポリシー・オートメーションを実装するために次のステップを実行します。まず、サービスとしてのポリシーを購読する設定を行い、サービスとしてのポリシーのプロバイダーとのサービス・レベル・アグリーメントを用意します。次に、サービスとしてのポリシーのプロバイダーからモデル駆動型セキュリティー・オートメーション・ソフトウェアおよびポリシー実施/監視ソフトウェアを入手し、それぞれ PaaS マッシュアップ/開発ツール、ランライム・プラットフォームにインストールします。さらに、エンド・ユーザー組織に対して、関連するセキュリティー・ポリシー購読オプション、マニュアル、そしてサービスとしてのポリシーのプロバイダーによって作成されるコンプライアンス・レポートへのアクセスを提供しなければなりません。近いうちに、このようなサービスを提供する可能性が大きいプロバイダーは、パブリック・クラウド・プロバイダーではなく、プライベート・クラウド・プロバイダーです。プライベート・クラウドは、よりミッション・クリティカルな用途で使用されるためです。

新しい概念なのか、以前に使用された概念なのか

例えば Web アプリケーションをテストする場合、クラウド・サービス (サービスとしてのセキュリティー) として使用できるセキュリティー・ツールも一部にあります。ただし、承認管理を目的としたモデル駆動型セキュリティーがクラウド・サービス (サービスとしてのポリシー) として実装されたことは、(著者の知る限り) これまでありません。その主な理由は、PEP の場合は尚更のこと、標準の採用に時間がかかっているためです。著者は OpenPMF リファレンス実装でこの問題を回避するために、クラウド・プロバイダーと直接連携しました (「事例研究」を参照)。この直接の連携により、クラウド・プロバイダーのインフラストラクチャーに適切な統合ポイントを展開することができました。


事例研究

このセクションでは、2 つの事例を取り上げます。

プライベート・クラウドの場合のアプリケーション・セキュリティー・ポリシー・オートメーション

ObjectSecurity の OpenPMFは、多種多様な技術を対象としたアプリケーション・セキュリティー・ポリシー・オートメーションを実装しています。従来のインストールでは、OpenPMF はローカル開発、オーケストレーション、およびコンプライアンス監視/レポート作成ツールのアドオンとして使用されており、多数のプラットフォーム (各種 Web アプリケーション・サーバー、Java EE、DDS (Data Distribution Service)、CCM (CORBA/CORBA Component Model)) 上のアプリケーションを保護する目的で、ローカルにインストールされた開発ツール (Eclipse、Intalio BPMS など) の内部に常駐されるか、この開発ツールと一緒に常駐されます。けれども PaaS の登場により、OpenPMF 自体もクラウド・サービスとしてオンデマンドで使用できるようにすることが当然のことになりました。

例えば、プライベート・クラウドのアプリケーション・セキュリティー・オートメーションについて言うと、上述のローカル・ポリシー・オートメーションからクラウド・ベースのポリシー・オートメーションへの移行は、Intalio クラウドに統合されています。Intalio クラウドはフルスタックのオープンソースによるクラウド・オファリングであり、ビジネス・プロセス・モデリングを使用したアプリケーション開発および統合 (以降に記載する図を参照)、そして Web サービス・ベースのランタイム・プラットフォームなど、ポリシー・オートメーションに必要な前提条件が組み込まれています。OpenPMF の現行の技術統合は、開発 (Intalio BPMS/Eclipse)、ランタイム (Apache Axis2)、および認証/暗号化 (SSL (Secure Sockets Layer)/TLS (Transport Layer Security)) に対して行われています。図 3 に、BPM Web サービス・オーケストレーション・ツールに組み込まれているポリシー・オートメーション機能を示します (「OpenPMF」 > 「Generate Security Policy (セキュリティー・ポリシーの生成)」の順にメニューを選択)。アプリケーションをクリックすると、そのアプリケーションの技術的なセキュリティー・ルールの詳細が自動的に生成されます (図 4 を参照)。

図 2. インストール (クラウド・プラットフォーム・プロバイダーの場合)
インストール (クラウド・プラットフォーム・プロバイダーの場合)
図 3. ポリシーの自動生成 (PaaS ユーザーの場合)
ポリシーの自動生成 (PaaS ユーザーの場合)
図 4. 技術的なポリシーのデプロイメント (PaaS ユーザーの場合、あるいはすべて非表示の場合)
技術的なポリシーのデプロイメント (PaaS ユーザーの場合、あるいはすべて非表示の場合)
図 5. 実行時の監視 (ユーザーおよびサービスとしてのポリシーのプロバイダー)
実行時の監視 (ユーザーおよびサービスとしてのポリシーのプロバイダー)

クラウドおよび SOA の場合のモデル駆動型セキュリティー・ポリシー・オートメーション

現在、米海軍で実際に運用するためのモデル駆動型セキュリティー・ポリシー・オートメーションの実装が ObjectSecurity によって行われています。ObjectSecurity はアプリケーション・ポリシー・オートメーションのベンダーで、その主な契約業者である Promia は、セキュア技術を政府および業界に提供しています。この現在実装しているモデル駆動型セキュリティー・ポリシー・オートメーションは、アプリケーション、ミドルウェア、仮想マシン、オペレーティング・システム、そしてネットワークをはじめ、クラウドと SOA スタックのすべての層に対処している点で、この記事で説明した内容よりも包括的なものです。このプロジェクトは、相互に接続された動的に変化する SOA およびクラウド・アプリケーションの情報保証を効率良く管理するための有効な手段となります。特にアジャイルな変更、迅速な認証および認定、そして柔軟なポリシー管理を促進することができます。

使用されている技術 (図 6 を参照) は、次のとおりです。ObjectSecurity の OpenPMF による、モデル駆動型セキュリティー、アプリケーション・セキュリティー監視、およびポリシー管理。Promia の Raven による侵入検知、監視、監査、および XML 情報交換機能。セキュアな開発ライフサイクルを実施するセキュリティー対応クラウドおよび SOA 開発/デプロイメント・ツール。権限を分散するためのスケーラブルな ZBAC (Authorization Based Access Control)。SOA/クラウド・アプリケーションと保護機能をホストするフルスタックの保護機能で強化された信頼できるランタイム・プラットフォーム。グローバルなフルスタックのポリシー管理およびオートメーション、レポート作成、認定オートメーションおよび意思決定サポート、構成、バージョン管理、スキャン、テストといった機能を備えた管理システムです。

図 6. モデル駆動型セキュリティー・ポリシー・オートメーションの実装
Implementation of model-driven security policy automation

まとめ

この記事で説明したのは、クラウド・マッシュアップなどのアジャイルな分散アプリケーション環境の場合、セキュリティーおよびコンプライアンス・ポリシー管理にアジリティー、管理容易性、信頼性、そしてスケーラビリティーをもたらすには、モデル駆動型にして、自動化しなければならないということです。これには、2 つの中核的な概念が関係してきます。第一に、ポリシー構成を購読ベースのクラウド・サービスとしてアプリケーション開発ツールに提供するという概念 (サービスとしてのポリシー)、そして第二に、技術的なポリシーの生成、実施、監査、更新をクラウド・アプリケーションのデプロイメントおよびランタイム・プラットフォームに組み込むという概念です。クラウド・アプリケーションおよびクラウド・マッシュアップ用のセキュリティー・ポリシー・オートメーションとコンプライアンス・ポリシー・オートメーションをクラウドに移すことにより、クラウド導入の背後にある論拠全体の中で、クラウド・アプリケーションとクラウド・マッシュアップが一層シームレスに保護されます。また、これによって、クラウド・アプリケーションのセキュアなソフトウェア開発ライフサイクルが改善され、単純化されることにもなります。

これから先、皆さんがモデル駆動型セキュリティー・オートメーションを導入する際には、以下の具体的な推奨事項があります。

  • 試してみること
    クラウド・プロバイダーに推奨するのは、セキュリティー・ポリシー・オートメーションをプラットフォームに組み込んでみることです (例えば、Eclipse 対応の ObjectSecurity 試用版を無料で入手して導入できます)。クラウド・ユーザーに対しては、モデル駆動型マッシュアップとポリシー・オートメーションをサポートしているか、または少なくとも承認管理をサポートしている IaaS または PaaS クラウドでクラウド・アプリケーションを構築している場合には、モデル駆動型セキュリティー・ポリシー・オートメーションを試してみることをお勧めします (ObjectSecurity の Intalio Cloud 用ツールの試用版を無料で入手できます)。
  • 構想を計画して、それを売り込むこと
    クラウド導入の計画段階では、最初からポリシー・オートメーションを実装することはないとしても、ポリシー・オートメーションをサポートするアーキテクチャーを計画してください。モデル駆動型マッシュアップ・ツールは、ポリシー・オートメーションをサポートする上で特に有効です。そしてポリシー・オートメーションとマッシュアップ・ツールの両方を経営陣に売り込む際には、「個々を合わせることで、それ以上の力が生まれる」という主張を使えます。
  • 可能な場合には、クラウド・プロバイダーにポリシー・オートメーションを要求すること
    クラウド・プロバイダーに、技術と手法を保有していること、そしてこれらの技術と手法がクラウド・セキュリティーをより高いコスト効率で扱う上でいかに役立つかを示してください。デフォルトでクラウド・プロバイダーが提示するのは、セキュリティー専門家がその最善の役割を果たす上で助けにならない、「受けるか否か」のクラウド・オファリングという感があります。残念ながら、一部のクラウド・プロバイダー (特に PaaS のプロバイダー) はそのインフラストラクチャーを公開していないため、ユーザー独自のポリシー・オートメーション製品を統合するのは容易ではありません。セキュリティー専門家は、適切な質問をすることで、クラウド・プロバイダーを正しい方向に動かすか、よりオープンなクラウド・プロバイダーを選ぶ必要があります。
  • 適切な場合にはサード・パーティーによるサービスとしてのポリシーを統合すること
    大規模な組織のプライベート・クラウドをデプロイする場合には、標準をベースとしたサード・パーティーのクラウド・アプリケーション・セキュリティー・ポリシー・オートメーション製品を使用することを検討してください。サード・パーティーの製品を使用すると、サード・パーティーのセキュリティー・スペシャリストを通して、サービスとしてのポリシーを購読できると同時に、クラウド・プロバイダーの標準ベースの機能 (XACML (eXtensible Access Control Markup Language) など) によってアプリケーション層のセキュリティーが実施されます。
  • 適切な場合にはサード・パーティーのインシデント監視および分析サービスを統合すること
    上記の推奨事項は、監視にも当てはまります。必要なものをクラウド・プロバイダーが提供していない場合には、サード・パーティーの製品でアラートを処理できるように、標準的なフォーマット (syslog など) でアラートをエクスポートできることを確実にしてください。

参考文献

学ぶために

  • ObjectSecurity の OpenPMF は、セキュアなアプリケーションの開発、操作、維持を支援する手段として、アクセス制御および監査に対するアプリケーション・セキュリティー・ポリシーの管理を容易にします。
  • Access Policies for Middleware」には、参考となるモデル駆動型セキュリティーの模範的な例が記載されています。
  • developerWorks のクラウド開発者向けリソースで、クラウド開発プロジェクトを作成しているアプリケーションおよびサービス開発者たちの知識と経験を調べて共有してください。
  • IBM developerWorks Industry ゾーンで、特定の業界の開発者にとって興味深い、業界別の技術記事、チュートリアル、コミュニティー、Wiki、ビジネス・リソースを調べてください。

製品や技術を入手するために

  • IBM Smart Business Development and Test on the IBM Cloud で使用できる製品イメージを調べてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, SOA and web services
ArticleID=659361
ArticleTitle=モデル駆動型クラウド・セキュリティー
publish-date=02082011