はじめに

情報へのアクセスをセキュアにすることは、どんなアプリケーションにとっても基本的なことです。SOAの原則に従って構成される実装では、サービスやアプリケーション、またそれらのオペレーション（組織境界を越えて行われます）が疎結合となるため、セキュリティーは一層重要になります。こうした環境では、多くの場合、既存のセキュリティー実装の微妙な部分や制限などが露出されることになります。

ビジネス・アプリケーションは、モデル駆動型開発やSOAベースのサービス管理によってもたらされる効率性とは無関係に、情報をセキュアに保つ必要があります。オンデマンド・ビジネスは、パートナーや顧客、従業員などの間の関係変化に対応して信頼関係を動的に確立、分解できる必要があるため、単に周辺部分（ファイアーウォールやルーター）をセキュアにするだけでは充分ではありません。従ってオンデマンド・ビジネスがセキュアであるためには、新しい要求や規制に対応できるような、柔軟でカスタム化可能なインフラが必要です。そうした柔軟性を実現するためには、ポリシーをインフラの中に固定化すべきではありません。セキュリティー・モデルが要求するものを、ポリシー駆動型のインフラによって実装すべきなのです。しかし、これは単純なことではありません。

この記事では、オンデマンドのセキュリティー・インフラが持つセキュリティー機能をビジネス・アプリケーションで活用する方法について、そしてサービス指向アプリケーションをセキュアにするためのプログラミング・モデルの設計原則について解説します。

上に戻る

ビジネス・アプリケーションとセキュリティー・インフラ

ビジネス・アプリケーションや情報をセキュアに統合し、またそれらに対するセキュアなアクセスを実現するためには、通常は認証や許可、責任能力（accountability）などが必要です。ビジネスが、認証や許可、責任能力などの管理に対してどのような手法を取るかは、顧客や従業員、パートナーの間に存在する信頼関係の捉え方、そうした関係がビジネス・アプリケーションにもたらす影響の度合い、そうしたアプリケーションの相対的な重要性やセキュリティー、などによって影響されます。

機密性の高い情報をビジネス・パートナーの間で交換する場合は、その情報をセキュアにする必要があります。またその情報は、セキュアに永続する必要があるかも知れません。必要な場合には検証や監査、否認防止が可能なように、メッセージの発信元の整合性も（例えば公証（notary）サービスなどによって）保証されている必要があります。機密性の高い情報は、機密性を維持するために暗号化するか、あるいは整合性を保つためにデジタル署名しておく必要もあるかも知れません。（デジタル署名は、否認防止にも役立ちます。）完全なSOAセキュリティー設計では、メッセージ・レベルやトランスポート・レベルでのセキュリティーに対応するだけではなく、政府による規制や業界のベスト・プラクティスに合致するよう、永続コンテンツ（persisted content）をセキュアに保つ必要もあります。

基本的に、セキュリティー・ポリシーの定義や強制を支配するのは、また強制されるセキュリティー・レベルを決定するのは、ビジネスとその従業員、顧客、パートナーなどの間での信頼関係です。こうした信頼関係を反映し、管理するために、証明書や暗号鍵などのセキュリティー関連技術が使われます。ビジネス・パートナー同士、顧客とビジネスとの間などの信頼関係をモデル化し、規定するために、ツールを使うこともできます。またツールによって、信頼の定義を、IT環境に適した技術へと変換することができます。

上に戻る

SOAのセキュリティー・モデル

SOAのセキュリティー・モデルは、Webサービスが着信メッセージに対して、一連の要求（claim）を証明するよう求める、というプロセスに基づいています。こうした要求の例としては、名前や鍵、パーミッション、能力（capability）などがあります。提供される証明に基づいて、リクエスターやサービス・エンドポイント、仲介候補などの間に、適当な信頼モデルが適用されます。

メッセージは、リクエスターとターゲット・サービスとの間にある、幾つかの仲介をトラバースする場合もあります。セキュリティー管理をエンド・ツー・エンドで行うためには、リクエスターと仲介、最終的なエンドポイント・サービス（プロバイダー）との間での信頼モデルを考慮する必要があります。これを 図1 に示します。

ネットワークとトランスポートの仲介（例えばファイアーウォールやルーター、プロキシー・サーバーなど）は、一般的にメッセージ処理に関しては信頼されません。伝送中の全メッセージは、信頼できない仲介による改ざんから保護されている必要があります。

OASISのWSS（Web Services Security）仕様は、伝送中のSOAP（Simple Object Access Protocol）メッセージに対する保護を提供しています。WSSを利用することによって、メッセージの認証性や整合性、機密性を、信頼できないネットワーク仲介やトランスポート仲介から保護することができます。

全ての仲介が信頼できないわけではありません。Webサービスのゲートウェイや、ESBの調停（mediation）サービスは、メッセージ変換のための仲介の例であり、これらはSOAにおいて、メッセージ・ペイロードに対する検査（inspection）や、場合によっては修正、といった機能を果たします。（このシリーズの第4回: 「 IBM Enterprise Service Bus入門 」、developerworks, 2005年を見てください。）SOAセキュリティー・インフラを設計する際には、信頼できる仲介も幾つか許せるように考慮する必要があります。

信頼できる仲介の、もう一つの例としては、リクエスターとアプリケーション・サービス・ホストとの間での信頼関係を処理するメッセージ・ブローカーがあります。この設計では、セキュリティーの責任は、ブローカーとサービス・エンドポイントとの間で分割されます。メッセージ仲介は、メッセージ・レベルでのセキュリティーや、リクエスターとプロバイダー環境との間でのIDフェデレーション、リクエスターとサービス・プロバイダー間の信頼関係の管理などに責任を持ちます（ 図2 ）。一方サービスは、サービス特有のセキュリティー要求に応えることにのみ責任を持ちます（こうしたセキュリティー要求としては、例えばメッセージ・ペイロード中のアプリケーション特有データが持つサービスや整合性、機密性にアクセスするための、（マップされ、仲介によってフェデレートされた）ID確立などがあります）。SOAベースのセキュリティー手法では、ビジネス・アプリケーションから脆弱で複雑なインフラ・コードを排除し、それらをコンテナーに任せることによって、柔軟性を高め、またトラブルの可能性を低下させることができます。

上に戻る

メッセージのセキュリティー

WSS仕様では、Webサービス開発者がセキュアにSOAP交換を行えるよう、整合性や機密性、認証に関するメッセージ・レベルでの基本機構も提供しています。こうした機構は様々な方法で組み合わせることができ、また様々な暗号技術を利用することによって、非常に多様なセキュリティー・モデルを構築することができます。

またWSSは、セキュリティー・トークンとメッセージを関連付けるための拡張可能な機構も用意しており、認証や許可に関する様々なフォーマットや機構に対応することができます。例えば、あるクライアントが、ID証明と、ある特定なビジネス認定を持っていることを示す署名付き要求を提供する場合があるかも知れません。そうすると、そうしたメッセージを受信するWebサービスは、その要求を信頼すべきかどうか、そしてどの程度まで信頼すべきかを判断します。

セキュリティー・トークン要求は、オーソリティー（authority）によって裏書きされるか、あるいは裏書きされないままに置かれます。通常、裏書きされた要求は、デジタル署名付きの、あるいはオーソリティーによって暗号保護された、セキュリティー・トークンとして表現されます。署名付きセキュリティー・トークンの、おなじみの例としては、X.509証明書（その人のIDと、公開鍵との間の関係を主張します）があります。セキュリティー・トークンは、メッセージの中に「プッシュ」する、つまりメッセージに入れて運ぶことができ、また、受信側がオーソリティーから要求を「プル」できるように、参照によって表現することができます。

セキュリティー・トークンが有用なのは信頼領域（trust domain）の中であるため、信頼領域の範囲を規定するための方法が必要です。これには、手動による規定方法、合意による方法、あるいは信頼ポリシーを強制するルール・セットを実装することで行う方法があります。こうした方法によって、裏書きされていない要求であっても、送信側と受信側との間に信頼関係が確立されている場合には、その要求は信頼できるものになります。例えば送信者と受信者が、（ネットワーク帯域外での信頼関係に基づいて確立した）信頼できるコネクションを使用している場合には、送信者がBobであれば、それが裏書きされていない要求であっても、ある受信者にとっては実際に送信者がBobであると信じるのに充分、ということになります。この例では、こうした信頼できるコネクションが存在することだけで、証明としては充分かも知れないのです。

メッセージ内容を不正アクセスから守る（機密性）、あるいは不正な修正から守る（整合性）ことは、セキュリティーに関する基本事項です。WSS仕様では、メッセージ本体やヘッダー、添付、またはこれらを任意に組み合わせたもの（あるいは部分）を暗号化、そして/あるいはデジタル署名することによって、メッセージを保護するための手段を用意しています。

リクエストの認証は、ネットワークとトランスポートがオプションとして提供するセキュリティーと、メッセージ中で証明される情報（要求）とを組み合わせることで行われます。これは、メッセージ認証（message origin authentication）として知られる手法です。リクエスターは、ネットワークやトランスポートが提供するセキュリティーや、メッセージの中で証明される要求、受信者が知っている鍵を使った要求暗号化などを使って、受信者を認証することができます。

上に戻る

信頼モデル

セキュリティー・トークンの使用許可を示す方法の一つは、（所有証明トークン（proof-of-possession token）からの）関連秘密鍵を使ったデジタル署名を含むようにすることです。こうすればリクエスターは、セキュリティー・トークン（例えばPKIX（Public Key Infrastructure for X.509 Certificates）またはX.509証明書など）とメッセージとを関連付けることによって、一連の要求を証明することができます。

もしリクエスターが、サービスに対する要求を証明するためのトークンを持っていない場合には、適当なオーソリティー（私達はセキュリティー・トークン・サービスと呼びます）に連絡し、適当な要求を持ったトークンを請求します。セキュリティー・トークン・サービスは信頼の基礎を構成するものであり、様々な種類のセキュリティー・トークン（様々な信頼領域の間で信頼関係をブローカーとして仲介するために使用されます）を発行します。

こうした1つの機構が、WS-Trustの中で定義されている、ユーザー確認のための質問応答プロトコル（challenge-response protocol）を使うことです（WS-Trustの仕様については、 参考文献 を見てください）。これは、Webサービスがリクエスターに対して追加質問する場合に使用します（追加質問によって、メッセージの新鮮さを保証し、またセキュリティー・トークンの使い方が許可されていることを証明するのです）。このモデルを 図3 に示します。この図では、リクエスターがサービスでもあり得る場合、またリクエスターとターゲット・サービスとの間に、サードパーティーによる信頼できるセキュリティー・トークン・サービスが使われ得る場合を示しています。（こうしたサービスは、ターゲット・サービスのポリシーに要求されるセキュリティー・トークンの検証に役立ちます。）

こうしたSOAセキュリティー・モデル（つまり要求やポリシー、セキュリティー・トークンなど）では、より特定なモデル、つまりIDに基づく許可、アクセス制御リスト、機能に基づく許可などを幾つか含み、またサポートしています。このモデルでは、既存の技術を使用することができます（例えばX.509公開鍵証明書や、XMLベース・トークン、Kerberos共有秘密チケット（Kerberos shared-secret ticket）、さらにはパスワード・ダイジェストまで）。SOAセキュリティー・モデルをWSSC（Web Services Secure Conversation Language）やWeb Services Policy Frameworkのプリミティブとを組み合わせれば、より高度なレベルでの鍵交換や、許可、ポリシーに基づくアクセス制御、監査、複雑な信頼関係などを構築するためには充分です。

Webサービスは、そのサービスに適用されるポリシーを持っており、リクエスター（セキュリティー・トークンを含んでいるかも知れません）からメッセージを受信し、また場合によると、WSSC機構を使って適用される、何らかの保護機構を持っているかも知れません。Webサービスの信頼エンジンが実行する主なステップには、次のようなものがあります。

• トークンの中にある要求がポリシーを充分満足しているかどうか、そして、メッセージがポリシーに従っているかどうかを検証する。
• 要求者（claimant）の属性が、署名によって証明されていることを検証する。ブローカー仲介による信頼モデルでは、署名では要求者の身元を証明できず、仲介者（要求者の身元を単純に主張する）の身元を証明してしまうかも知れません。要求は、証明されているか、あるいは、ポリシーに基づくものではありません。
• セキュリティー・トークン（関係するトークンや、発行中のセキュリティー・トークンすべてを含む）の発行者が、そうした要求を発行できる者と信頼できるかを検証する。信頼エンジンは、トークンを外部的に検証するか、あるいはブローカー仲介する（つまり、評価の中で直接使用する、他のセキュリティー・トークンと交換するために、トークンをセキュリティー・トークン・サービスに送信する）必要があるかも知れません。

こうした条件に合致し、リクエスターがオペレーション実行を許可されると、サービスはサービス・リクエストを処理します。

ネットワークやトランスポートの保護機構（IPSec（IP Security）やTLS/SSL（Transport Layer Security/Secure Sockets Layer）など）を、このSOAセキュリティー・モデルと組み合わせると、様々なセキュリティー要求やシナリオをサポートすることができます。もしネットワークやトランスポートのセキュリティー機構がある場合には、リクエスターは、セキュリティー・トークンの発行や検証、更新などの際に受信者を事前認証するために、そうした機構を利用してセキュリティー・レベルを上げることを考えるべきでしょう。

上に戻る

プログラミング・モデル設計の原則

セキュリティーの観点から見ると、プログラミング・モデルには、誰がセキュリティー・ポリシー（インフラやアプリケーションなど）の強制に責任を持つか、この情報のどれをリクエスターに利用できるようにすべきか、といった判断事項が含まれます。オペレーションの面でのポリシーに加えて、設計時にもポリシーを多少考慮すれば（例えばJ2EEデプロイメント記述子の中に含める、など）、アプリケーション管理に役立ちます。実装に関して判断すべき重要事項の1つは、そのビジネスで必要とするものを満足するために、インフラでセキュリティー・モデルを実現することが適切なのか、あるいは各アプリケーションの中にセキュリティー強制を入れ込むことが適切なのか、という点です。もう1つ考慮すべき面として、サービス呼び出しの変化度合いが挙げられます。つまり、サービス・コンシューマーには、購読中にカスタム化可能なだけの柔軟性が与えられているのか、という問題です。最後に、セキュアなソリューションを実装する際には、常にセキュリティー・エンジニアリング（つまり、セキュアなアプリケーション構築のためのエンジニアリング手法）を考慮すべきでしょう。

上に戻る

インフラ管理のセキュリティー対アプリケーション管理のセキュリティー

組織は通常、その組織のセキュリティー・ポリシーを特定し、強制するための責任を、一部の人達に与えます。多くの場合、このプロセスは手動で行われるため、様々な実体やアプリケーションにまたがるアクセスを調整するために、組織はかなりのリソースを費やす羽目になります。

私達の推奨としては、複雑な組織では、ソリューションに関連したセキュリティー・ポリシーの強制をインフラの中に中央化することです。つまり、一貫性のある方法を保証するために、ユーザー質問（例えばユーザーIDやパスワード）の検証や、アプリケーションへのアクセス制御（例えばtravelServiceに対するreserve() メソッド）、ID委任（例えばrun-as travelAgency id）などを、インフラの中に中央化するのです。アプリケーションに関する最初のセキュリティー・ポリシーは、一部のデプロイメント成果物（例えばJ2EEアプリケーションのデプロイメント記述子）の中で定義することができます。そしてデプロイ後、そのアプリケーション・ロジックが広く知られた後には、そのポリシー情報をデプロイメント環境で利用できるようになります。またポリシー宣言を高位のポリシー要求の中に抽象化しておけば、後のデプロイメント・フェーズで実装の制約を考慮する際に、その宣言を改善することができます。

アプリケーション設計では、インフラ管理によるセキュリティーか、アプリケーション管理によるセキュリティーかという判断を下す必要が出てきます。セキュリティーに関する制約や条件は、実装成果物に付属しています。インフラにセキュリティーを処理させるべきか、あるいはアプリケーションの中にセキュリティーを入れ込むべきかを判断すべき時期は、アプリケーション・プラットフォーム（J2EE（Java ™ 2 Platform, Enterprise Edition）やMicrosoft ® .NET）に関する情報が得られる、実装フェーズの期間中です。

私達の推奨としては、アプリケーションはビジネス・ロジックに集中すること、そしてサービスへのアクセスやメッセージをセキュアにすることに関してはインフラ（アプリケーションをホストするランタイム・コンテナー）に任せることです。この、インフラ管理による方法では、設計成果物に付属するセキュリティー・ポリシーは、プラットフォーム特有のポリシーに変換されます（例えば、UML（Unified Modeling Language）モデルを使って表現された要求は、J2EEデプロイメント記述子に変換されます）。

アプリケーション管理による方法では、セキュリティーの強制はアプリケーションの中で行われます。そして、適当なセキュリティー・コールアウトを実装する必要があります。たとえアプリケーションが管理するセキュリティーであっても、そのセキュリティー・コールアウト（例えばauthenticate() など）を、適当な、プラットフォーム特有の機能（JAAS（Java Authentication and Authorization Service）を使ったloginContext.login() など）に変換する必要があります。

許可やアクセス制御は、非常に粗いものから細かいものまで、様々です。キメの粗いアクセス（ソリューション自体にアクセス）を選択するか、キメの細かいアクセス（ソリューションのオペレーションにまでアクセス）を選択するかは、通常、ビジネス上、技術上の考慮事項に依存します。また、キメの細かさは、様々な要因によっても影響されます。こうした要因としては、情報実体（ある旅行者に対するクレジット情報プロファイルなど）のインスタンスや、ユーザー属性（例えば旅行代理店）などのコンテキスト情報、時間的制約（9時から5時、など）、アクセス目的（旅行予約の目的など）、アクセス・パス（イントラネット経由か外部リクエストか、など）、その他非常に多くのものがあります。

許可（authorization）に関連したポリシーは、アプリケーション・ロール（role）を定義することによって抽象化することができます。ここで言うロールは、あるアプリケーション・リソースに対して、あるアクションを行うためのパーミッションを集めたものです。例えば旅行のアプリケーションの場合、ReservationBeanに対する予約メソッドのview() やchange() にアクセスできるのはTravelAgentというロールである、と宣言することができます。つまりTravelAgentは実装定義のロールであり、対象とするEJB（Enterprise JavaBeans）に対する特定メソッドを呼び出すためのパーミッションに関して、「travel agent（旅行代理店）」は何ができるのかを規定するのです。実装フェーズ中に定義されない可能性のあるものとしては、誰がTravelAgentの特権を持つか、という点です。通常、ユーザーとロールとの割り当ては、デプロイメント時に初期化され、その後は、アプリケーションのライフタイム全体に渡って管理されます。 リスト1 は、ロールに基づくメソッドのパーミッションを幾つか定義するコードの例を示しています。

                
<method-permission>
<role-name>TravelAgent</role-name>
<method>
<ejb-name>ReservationBean</ejb-name>
<method-permission>
<role-name>TravelAgent</role-name>
<method>
<ejb-name>ReservationBean</ejb-name>
<method-name> view</method-name>
<method-name> change</method-name>
</method> </method-permission>

あるビジネス・ロジックを実行する前に、認証されたID情報を必要とするアプリケーションは、その情報をインフラから取得する必要があります。例えばJ2EE環境では、ランタイムがユーザーのIDを（認証した後）確立します。そしてアプリケーションは、getCallerPrincipal() などのAPIを使って、この情報を取得します。

上に戻る

柔軟性の選択

クライアント・ランタイムによっては、サービスそのもの（例えば認証や整合性、機密性要求など）に対するアクセスに対して、ある種の要求や制約が課される場合があります。また、広範な種類のクライアント・ランタイム（ブラウザー・クライアントや非ブラウザー・クライアント、PDAシン・クライアントなど）をサポートした方が望ましいとも言えます。これを実現するためには、クライアント・ランタイムがメッセージ機密性を保証する必要があること、そしてユーザーのID証明（ユーザーID/パスワードや証明書）を提供する必要があることを表明するポリシーを公開します。認証のためのポリシーを抽象化する場合には、受け入れ可能な信用証明情報のタイプや、どの信用証明情報発行オーソリティーが信用できるのかに関する選択肢をリストアップします。

例えばTravelServiceというWebサービスは、あるタイプのセキュリティー・トークンを要求すること、また機密性要求がある、という意図を宣言します。実装は、この意図の宣言を、記述子を使ってサポートします。そうするとツールは、マシンレベルで必要な詳細（例えばWS-SecurityPolicy表現など）を生成します。これを リスト2 に示します。

                
<sp:SymmetricBinding>
<wsp:Policy>
<sp:ProtectionToken>
<wsp:Policy>
<sp:KerberosV5APREQToken
sp:IncludeToken=".../IncludeToken/Once" />
</wsp:Policy>
</sp:ProtectionToken>
<sp:SignBeforeEncrypting />
<sp:EncryptSignature />
</wsp:Policy>
</sp:SymmetricBinding>
<sp:SignedParts>
<sp:Body/>
<sp:Header
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
/>
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
</wsp:Policy>

上に戻る

セキュリティー・エンジニアリング

セキュアなソリューションを開発する場合のベスト・プラクティスの1つが、セキュリティー・エンジニアリングです。つまり、よく定義されたパターンに従うことによって、アプリケーションやサービス、あるいはコンポーネントは、設計者やユーザーの期待通りに振る舞うようになるのです。実装成果物に固有のリスクや、その設計、実装におけるリスクを考慮することによって（例えば効率的なメモリー管理を行い、秘密チャネルを回避する、など）、脆弱性の穴があくことを防止することができます。また、ツール・サポートやコード・レビューも、ソリューションがデプロイされる環境への危険を最小限にとどめる（あるいは完全に無くす）ために役立ちます。

上に戻る

まとめ

SOAプログラミング・モデルでは、各サービス呼び出しが、リクエスターとサービス・エンドポイントの両方に有効なセキュリティー・ポリシーを遵守する、ということを保証する必要があります。セキュリティー・インフラの持つ機能には、リクエスターを認証し、サービスへのアクセス許可を行う機能や、基礎となる信頼モデルに基づいてWebサービス・リクエスト全体に渡ってセキュリティー・コンテキストを伝達する機能、重要イベントを監査し、データと内容を効率的に保護する機能などが含まれます。そしてセキュリティー・インフラによって、セキュアなコンポーネントやサービスを実現するためのSOA環境を構成することができます。あらゆるSOAセキュリティーの中核となっているのは、ポリシーに基づくインフラと、ポリシー管理です。理想的には、SOAアプリケーションはビジネス・ロジックのみに専念し、セキュリティー・ポリシーの強制やインフラに対する信頼関係の処理は他に委任します。Webサービスのセキュリティー仕様に基づくセキュリティー・モデルと手法を活用すれば、サービス指向アプリケーションをセキュアにする、という課題に対応することができます。

参考文献

学ぶために

• OASISのWebサイトを訪れ、OASIS Web Services Security: SOAP Securityに関する情報を調べてください。
  
  
• このシリーズの第4回、「IBM Enterprise Service Bus入門」（developerWorks, 2005年）を読んでください。
  
  
• Web Services Trust Languageに関する情報を入手してください。
  
  
• Web Services Secure Trust Conversation Languageに関する情報を入手してください。
  
  
• Web Services Policy Frameworkについて学んでください。
  
  
• developerWorks の SOA and web services ゾーンでは、SOAやWebサービス技術に関するハウ・ツー情報やツール、プロジェクトの更新情報などを豊富に提供しています。
  
  
• このシリーズの他の記事も読んでください。
  
  
• developerWorks には、SOA や Web サービスに関する記事や、無料のチュートリアルが豊富に用意されていますので、ぜひご利用ください。
  
  

議論するために

• ディスカッション・フォーラムに参加してください。
  
  
• developerWorks ブログに参加して、developerWorksのコミュニティーに加わってください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• ビジネス・アプリケーションとセキュリティー・インフラ
• SOAのセキュリティー・モデル
• メッセージのセキュリティー
• 信頼モデル
• プログラミング・モデル設計の原則
• インフラ管理のセキュリティー対アプリケーション管理のセキュリティー
• 柔軟性の選択
• セキュリティー・エンジニアリング
• まとめ
• 参考文献
• 著者について
• コメント