レベル: 初級 John R. Betancourt (john.betancourt@gmail.com), President, Intelleges
2007年 7月 24日 このシリーズは、SOA (Service-Oriented Architecture) セキュリティーを実装するためのロードマップを提供します。このシリーズは 3 回構成ですが、今回はその第 1 回として、SOA セキュリティー・チームの編成から効果的な要件収集プロセスまでのすべてを行う上で役に立つ、10 ステップのプロセスを説明します。第 2 回では上位レベルの設計方法を学び、第 3 回ではテスト・ケースについて解説します。
私は最近、SOA プロジェクト、具体的には大規模な自動制御システム用のセキュリティーを実装するプロジェクトに従事する機会がありました。私はその件に関して、可能な限り多くの本を読み、オンラインで学習し、さらには過去に一緒に仕事をしたことがあるかつての同僚や友人にメールでメッセージを送ることまでしました。驚いたことに、大規模な SOA アプリケーションをセキュアにするという私の目標を実現するために必要な手順を、ステップごとのプロセスとして提示してくれるロードマップはなかったのです。
私は結局、自分で独自のロードマップを作らざるを得ませんでした。私が作成したのは単純な 10 ステップのプロセスですが、この記事ではその 10 ステップについて説明します。
ステップ 1. 適切なチームを編成する
大規模で重要なインフラのアプリケーションを SOA に移行する作業は、気が遠くなるほどの大仕事です。そうしたアプリケーションをセキュアにしようとすると、作業は一層困難になり、多くの場合はまったく新しい考え方を要求されます。さらには、セキュリティーに関して、まったく新しいチームが必要かもしれません。大部分のセキュリティー・チームは、SOA に関する訓練や、場合によるとプログラミングの訓練さえほとんど受けていません。セキュリティーに関するリーダーが通常とる方法としては、遠くから基本となる指針を伝え、あとは組織がそれに従うのを期待する、という方法です。そこで、ステップ 1 は (実はこれが最も困難なことが多いのですが)、適切なチームを編成することです。
セキュリティー・チームには、セキュリティーとソフトウェア・アーキテクチャー (できれば SOA ) の両方に知識を持つリーダーが必要です。EA (enterprise architect: エンタープライズ・アーキテクト) と同様、SEA (security enterprise architect: セキュリティー・エンタープライズ・アーキテクト) も全体的な SOA セキュリティー・モデルを作成します (このモデルは、さまざまなセキュリティー要件すべてを、あらゆるレベルの粒度で統合します)。SEA は、SOA ガバナンス審査委員会の一員として働き、EA と協力しながらすべての SOA 実装がセキュリティー要件に準拠することを確認し、そしてプロセス全体を通して必要な成果物を作成する SBA (security business analyst: セキュリティー・ビジネス・アナリスト) と SSE (security systems engineer: セキュリティー・システム・エンジニア) のチームのリーダーとして働きます。また SEA には、セキュリティー・サービスをコーディングするプログラマーやシステムのデプロイ前のテスト・フェーズを行うセキュリティー・システム・テスター達と協力して作業を行うという役割もあります。
ステップ 2. 詳細なプロジェクト・プランを作成する
大規模な SOA システムでのステップ 2 では、新しい SOA を古いセキュリティー・モデルに対応させることはできないこと、対応させようとしても動作しないのだということを、組織の上層部が理解する必要があります。もし、最初から従来のセキュリティー機構 (例えばファイアーウォールや侵入検出システム、セキュリティー・モニターなど) が焦点だとすると、それは SOA セキュリティー実装の本質が失われてしまいます。皆さんは、SOA セキュリティー実装の要件を明確にし、そしてそれを正確に反映した、詳細なプロジェクト・プランと予算案を作成し、必ず全員に「それを理解」させる必要があります。
また、SOA モデルに変換することによって、セキュリティーに特有の逆説が生ずることも理解させる必要があります。つまり、システムが SOA を採用すればするほど、システムはセキュアでなくなるのです。サービス指向のモデリングと分析手法によって現在のシステムを SOA に変換するプロセスでは、ビジネス設計の文書化が必要です。ビジネス設計と情報システムとを関連付ける正式な言語を使うことによって、SOA ではないシステムがいかに矛盾しており、非効率であり、そして複雑であるかがわかることがよくあります。しかしこの複雑さによって、無数の問題を隠すことができ、エンタープライズ・システムに害を加えようとする者がそうした問題点を見つけにくくなります。こうしたシステムを整理して SOA を採用すると、悪意のユーザーにとって攻撃しやすい単純なアーキテクチャーになります。
SOA の信奉者は同意しないかもしれませんが、システムをセキュアにすることに責任を持つ人達は、Web 対応で中央制御ポイントを持つオープン・システムが本質的にあまりセキュアではなく、従来よりも受動的で柔軟な方法が要求されることを知っています。この問題には何も回避策はありません。プロジェクトを計画する人達 (SOA セキュリティーに関して、ある程度の責任を持つことが多いものです) は、SOA 実装によって提起される新たな課題をセキュリティー・チームが分析して理解するための時間を確保できるよう、SOA セキュリティーには詳細なプロジェクト・プランと予算案が必要なことを覚えておく必要があります。
ステップ 3. SOA 対応可能性セキュリティー判定マトリックスを持つ
SOA 対応可能性セキュリティー判定マトリックスを作成することで、上位レベルの SOA セキュリティーの動作を正式に文書化します。このマトリックスの中で、ビジネスの利害関係者はアプリケーションを 3 つのカテゴリーに分割します。これらのカテゴリーには次のものが含まれています。
- SOA 対応になるもの
- SOA 対応のアプリケーションと対話動作する必要があるもの
- SOA 対応にならず、SOA 対応のアプリケーションと対話動作する必要がないもの
これらの異なるカテゴリーを色分けすると便利です。例えば、私は最初のカテゴリーを赤に、2 番目のカテゴリーをオレンジ色に、3 番目のカテゴリーを黄色にします。
次にセキュリティー・チームが、セキュリティーのカテゴリー (高、中、低など) でアプリケーションをさらに分割します。例えば、マーケット情報や機密情報を扱うアプリケーションやサービスは最高のセキュリティー・カテゴリーですが、公開されているデータのみにアクセスするアプリケーションやサービスは最低のセキュリティー・カテゴリーです。
表 1 は、SOA 対応可能性セキュリティー判定マトリックスの一例です。
表 1. SOA 対応可能性セキュリティー判定マトリックス
| セキュリティー (高) | セキュリティー (中) | セキュリティー (低) |
|---|
| 赤 | 36 | 12 | 11 |
|---|
| オレンジ | 12 | 5 | 3 |
|---|
| 黄色 | 6 | 0 | 6 |
|---|
これを見ると、12 個のアプリケーション (黄色) が SOA 対応にならないことがわかります。従って、この作業には異種混合のセキュリティー・モデルが必要です。つまり、システムのうち SOA 対応の部分にセキュリティーを提供するセキュリティー・モデルと、SOA 対応ではない部分にセキュリティーを提供するセキュリティー・モデルという混成セキュリティー・モデルが必要なのです。通常、SOA 対応ではないセキュリティー・モデルは、ペリメーター・セキュリティー (perimeter-based security) と呼ばれるものに依存し、情報資産は何層かのファイアーウォールの背後でセキュアに保たれます。
SOA 対応のセキュリティーを構築するためには、リスク管理フレームワークを作成することから始めます。これをステップ 4 で説明します。
ステップ 4. リスク管理フレームワークの方法を使って暫定案を作成する
ステップ 4 では、「内部からのセキュリティー (security from within)」の方法を使います。内部からのセキュリティーという意味は、セキュリティーに関する考慮事項と SOA 実装内部でのすべての動作とが一致しているということです。SOA 実装の動作を調べるために、設計文書を調べ、セキュリティー上の判定を行う必要があるポイントに注目し、これらのセキュリティー上の判定を実施するセキュリティー制御ポイントを特定する必要があります。
必要に応じてアプリケーションや SOA セキュリティー・サービス、SOA コンポーネントなどに、こうしたセキュリティー・ポリシーを守る役割を割り当てることによって、セキュリティー・ポリシーを適用して実施するために、さまざまな仕組みを使用します。
セキュリティー要件を、SOA 実装全体にわたって動作する一連のセキュリティー・サービスにカプセル化したり分解したりすることも視野に入れる必要があります。例えば、ユーザーを認証するためのタスクであれば、すべてのアプリケーションが利用でき、対話動作できる、認証セキュリティー・サービスに割り当てることができます。またそれとは対照的に、ESB (enterprise service bus) を構成することで、アプリケーションごとに一定のメッセージしかアクセスできないように制限をかけることもできます。(これについての詳細は第 2 回に解説します)。
SOA セキュリティー・サービスは、疎結合でモジュール構成、カプセル化、再利用、構成可能といった一般的な SOA の原則に従う必要があります。それによって大きな柔軟性が生まれ、情報システムがビジネス設計で要求される変化の速さに確実についていけるようになり、また組織の全体的なセキュリティーを高めるための変化を情報システムが推進していけるようにすることができます。そのためには、従来の静的なセキュリティー・モデルから、SOA のアーキテクチャーでの高速な変化に追従できる動的なモデルに移行する必要があります。
内部からのセキュリティーの方法とは別に、リスク管理に基づく方法も同時に維持する必要があります。ステップ 3 から、一部のデータは他のデータよりもセキュアでなければならないことや、一部のアプリケーションは他のアプリケーションよりもオープンでなければならない、等々がわかります。従って、すべてのメッセージとアプリケーションを同じに扱うべきではありません。すべてを同じに扱ってしまうと、システム全体に不必要なセキュリティーの負担がかかり、それがパフォーマンスとシステム全体としての使いやすさに影響を与えます。全体的なリスク管理戦略の一部として、セキュリティーの要求とシステム全体としての使いやすさをバランスさせる必要があります。
Gary McGraw による非常に有用な本 (「参考文献」を参照) は、RMF (risk-management framework: リスク管理フレームワーク) を作成する上で役立つ、5 つの部分から成るプロセスについて詳述しています。基本的には、下記のプロセスが必要だということです。
- ビジネス・コンテキストを理解する
- ビジネス上のリスクと技術上のリスクを特定する
- リスクを総合的に考え、ランク付けする
- リスクの軽減策を定義する
- 修正を実行し、検証する
例えばビジネス・コンテキストを理解することを考えてみましょう。ベンダーが応札するシステムでは、各ベンダーはそのベンダー自身の情報にアクセスできる必要がありますが、他のベンダーのデータを見ることは不適切なことがわかります。このデータは、あるビジネス・コンテキストでしか分類できず、ステップ 3 で示したような単純な階層モデルを使って分類することはできません。
ステップ 5. 内部と外部の利害関係者を定義する
これらの方法を理解したら、今度はステップ 5 です。ステップ 5 では、SOA セキュリティー・チームは SOA セキュリティーの利害関係者を特定して、分離します。利害関係者は、外部と内部という 2 つのグループに分けられます。外部の政策立案機関や監督機関 (例えば NERC (North American Electric Reliability Corporation: 北米電力信頼度協議会) など) は、セキュリティーに関して広い意味合いを持つ特定のサイバーセキュリティー標準 (例えば CIP (Critical Infrastructure Protection: 重要インフラ保護) 要件など) を持っている可能性があります。
CIP は非常に多様な領域を網羅しており、その中には Security Management Controls (CIP-003-1) や Electronic Security Perimeter(s) (CIP-005-1)、Physical Security of Critical Cyber Assets (CIP-006-1)、Systems Security Management (CIP-007-1)、Incident Reporting and Response Planning (CIP-008-1)、そして Recovery Plans for Critical Cyber Assets (CIP-009-1) などがあります。これらの標準によって、全体としての SOA セキュリティー実装に影響する独自の特定要件が生成されます。
さらに、セキュリティーの SOP (Standard Operating Procedure: 標準運用手順) として書かれていることが多い内部セキュリティー要件を使うことで、誰が、何を、どこで、いつ、どのように、といったセキュリティーに関する質問に答えることができます。誰が、何に対して、いつ、どこで、どのように、どのくらい長くアクセスできるのでしょう。多くの組織では、この情報は長年にわたって有機的に進化してきており、整理されておらず、一貫性がありません。SOA 実装では、その組織のセキュリティー・ポリシーを正確に反映した系統だった文書を作り出すために、大きな努力が要求されることが多いものです。
ステップ 6. 要件の収集に適したツールを特定し、使用する
ステップ 6 では、要件の収集を始める前に、適切なツールを選択することが重要です。これらのツールは、チームが協力して SOA セキュリティー要件を容易に文書化でき、SOA セキュリティー・モデルを作成できるものでなければなりません。要件と分析のための適切なツールがあれば、チームがプロジェクトのライフサイクル全体を通して問題空間を理解し、進化し続ける要件を捉えて管理し、ユーザーとの対話動作をモデル化し、利害関係者のフィードバックを取り入れ、そして最も重要なこととして、協力して作業を行う上で、助けになります。
セキュリティーの要件と分析に関して適切な作業を行うことで、システムのセキュリティー・リスクを大幅に低くすることができます。IBM® Rational® の要件と分析のツールは、利害関係者の要求を的確に理解して表現する上で、また顧客やビジネスの要求の収集や検証を進めて調整する上で、システムに対する要件を文書化して整理する上で、そしてチーム全体に要件を伝える上で、非常に効果を発揮します。私は IBM Rational RequisitePro® と WebSphere® Business Modeler、そして Rational Software Architect を使いましたが、皆さんにもこれらをお勧めします。
ステップ 7. SDLC プロセスに従って SOA セキュリティーを実装する
収集しなければならない膨大な情報量や、作成しなければならないアーキテクチャー成果物の数、そして構築される特定の SOA セキュリティー・サービスのことを考慮すると、SOA セキュリティー・チームは次に示す SDLC (Software Development Life Cycle) の標準ステップに従う必要があります。
- セキュリティーの要求と制約を特定する
- セキュリティー要件を引き出し、収集する
- セキュアなアーキテクチャーを設計する
- セキュアな SOA 設計の詳細を文書化する
- (SOA ガバナンスを含めて) SOA を実装する
- テストする
- デプロイする
- 維持管理する
一見すると、これらのステップは明白に思えるかもしれませんが、セキュリティー・チームが SDLC プロセスを検討することは稀です。彼らは、ホワイト・ボードのある部屋に座って詳細な要件を書き出したり、セキュリティーを上位レベルで設計したり、そしてシステムの信頼性が高くセキュアなことを証明するために徹底的なテスト・ケースを作成したりすることには慣れていません。(上位レベルの設計とテスト・ケースについては、このシリーズの第 2 回と第 3 回で解説します。)
セキュリティー・チームは、ソリューションの設計を始める前に要件を収集する必要があります。セキュリティーの実装には、明示的な要件と暗黙的な要件の両方があります。明示的な要件に関しては、まずステップ 5 にリストした利害関係者それぞれの要件を収集することから始めるのが適切です。暗黙的な要件に関しては、例えば CIA (confidentiality, integrity, availability: 機密性、完全性、可用性) の 3 点セットなどのセキュリティー・フレームワークを使って、あらゆるセキュリティー・システムの特定の要求をリストすると便利です。CIA の 3 点セットは広く使われている IA (information assurance) モデルであり、すべての情報システムの基本的なセキュリティー特性として、機密性と完全性、そして可用性を特定します。
セキュリティー・チームは、この SOA 実装によってシステムの機密性 (つまりデータの秘匿性) がどう確保されるのかを考慮する必要があり、また、意図され許可された受信者や個人、プロセス、機器以外は転送中のメッセージにアクセスできないようにする方法を詳細に示す明確なプロセス・マップを作成する必要があります。許可されないエンティティー (例えば許可されないネットワーク・スニッフィングを使用する悪意のユーザーなど) にデータを公開することは機密性違反であり、SOA 実装は、システム全体の中の、いつ、どこで暗号化 (つまり機密データを保存して送信するための技術と科学) を使用するのかを指定する必要があります。
同様に、SOA セキュリティー・モデルには、完全性、つまりメッセージが変更されないという保証が必要です。SOA セキュリティーは、情報が送信されてから受信されるまでの伝送中に変更されなかったことの保証 (データの完全性) と、その情報の送信者が適切な送信者であることの保証 (送信側の完全性)、そして受信者が適切な受信者であることの保証 (受信側の完全性) に責任を持ちます。意図的に、あるいは事故によって、意図された受信者が情報を読む前にその情報が破損したり改変されたりすると、データの完全性が侵害されます。また、あるエージェントが素性を偽って不正な情報を受信者に提供すると、ソースの完全性が侵害されます。データの完全性を提供するために使われる機構としては、ディジタル署名とハッシュ・アルゴリズムがあります。
さらに、許可されたユーザーがデータ・サービスにタイムリーに信頼性をもってアクセスできること (可用性) も SOA セキュリティー要件です。つまり SOA 実装は、必要なときに情報やリソースを利用できるよう保証する必要があります。これはつまり、より広範なシステムが十分高速にリソースを利用でき、想定通りタスクを実行できるということです。もちろん機密性と完全性を保護することは可能ですが、たとえ保護したとしても、攻撃者はリソースの可用性を制限したり、あるいはまったく利用できなくしたりすることができます。特に、ESB などの SOA のシステム・コンポーネントが「メッセージの仲介」を行う場合には、可用性の高いプロトコルや完全に冗長なネットワーク・アーキテクチャー、そして (単一機器の故障がシステム全体の故障となる) SPOF (Single Point Of Failure) がまったくないシステム・ハードウェアについて、SOA セキュリティー要件のドキュメントの中に詳述し、システムの信頼性と堅牢性を確保する必要があります。SOA セキュリティー・チームは、これらの領域すべてを余すところなく特定すること、そして適切なユース・ケースを確実に文書化することに責任を持ち、また特定の要件について説明できる必要があります。
ステップ 8. 既存のモデルから発見し、学ぶ
SOA セキュリティー要件に関するチームが少し時間をかけてこれらの全要件を検討してみると、チームのメンバーは、サードパーティーのツールでは自分たちの要件すべてを満足できないことに気付くはずです。彼らは、特定の要求に対応する SOA セキュリティー・サービスをプログラムする必要があります。しかし新たなプログラムを開発するよりも、上位レベルの設計フェーズに進む前に既存のモデルを調べ、これまでに開発されているものを調べた方が、はるかに得策です。この、ステップ 8 では、Intelligrid (「参考文献」を参照) による下記モデルを検討するようにお勧めします。下にあげたものは、SOA セキュリティーの実装で提供する必要があると思われる一般的なセキュリティー・ユーティリティー・サービスのリストと説明です。これらのサービスの詳細については次回の記事で解説しますが、ここではリストだけを示すことにします。
- 監査共通サービス (Audit Common Service)
- アクセス・コントロールに対する許可サービス (Authorization Service for Access Control)
- 機密性サービス (Confidentiality Service)
- クレデンシャル (資格情報) 変換サービス (Credential Conversion Service)
- クレデンシャル更新サービス (Credential Renewal Service)
- 代行サービス (Delegation Service)
- ファイアーウォール・トラバーサル・サービス (Firewall Traversal Service)
- ID 確立サービス (Identity Establishment Service)
- ID マッピング・サービス (Identity Mapping Service)
- 情報完全性サービス (Information Integrity Service)
- ドメイン間セキュリティー・サービス (Inter-Domain Security Service)
- 否認防止サービス (Non-repudiation Service)
- パス・ルーティングと QoS サービス (Path Routing and QoS Service)
- セキュリティー・ポリシー・サービス (Security Policy Service)
- ポリシー交換サービス (Policy Exchange Service)
- プライバシー・サービス (Privacy Service)
- プロファイル・サービス (Profile Service、ユーザー・プロファイル・サービス)
- ID 品質サービス (Quality of Identity Service)
- DoS 攻撃に対するセキュリティー (Security Against Denial of Service)
- セキュリティー保証管理サービス (Security Assurance Management Service)
- セキュリティー・プロトコル・マッピング・サービス (Security Protocol Mapping Service)
- セキュリティー・サービス可用性発見サービス (Security Service Availability Discovery Service)
- シングル・サインオン・サービス (Single Sign-on Service)
- 信頼性確立サービス (Trust Establishment Service)
これらのサービスが全部必要という場合は稀かもしれません。SOA セキュリティー・チームは各サービスに要件をマッピングする必要があり、そのプロセスの次に、ステップ 7 で示した要件のすべてを満足するために必要なすべてのサービスに対して、SOA セキュリティー・モデルを作成する必要があります。
ステップ 9. WS-Security 標準に慣れる
このプロセスが完了すると、ステップ 9 に進むために十分な情報を収集できたことになります。ステップ 9 では、WS-Security 標準を調べ、特定の SOA セキュリティー実装に対してどの標準が当てはまるかを判断します。図 1 は、検討が必要なすべての WS-Security 標準を示した簡単な図です。
図 1. WS-Security 標準
より詳細なモデルができあがるにつれ、WS-Security を構成する広範な SOA セキュリティー標準に慣れる必要があり、またそれらの標準相互の関係と、標準と SOA セキュリティー・モデルの要件との関係を理解する必要があります。これらのセキュリティー標準は、セキュアなメッセージを作成するために SOA 実装全体を通して使われます。
ステップ 10. サードパーティー・ベンダーのための標準を開発する
最後にステップ 10 では、SOA セキュリティー・チームはサードパーティー・ベンダーのために、一連の標準と API (application program interface) を作成する必要があります。SOA の大きなセールス・ポイントとして、サードパーティー・ベンダーが提供するサービスにアクセスできることでシステムがオープンなアーキテクチャーを活用できる点があげられます。各ベンダーは SOA 実装のセキュリティー標準に慣れている必要があり、またそのベンダーのサービスが SOA 実装のセキュリティー・サービスとの間でどのように動作するのかを明確に理解している必要があります。
このプロセス全体の中で、生成されるすべての文書が同じ用語と定義を使えるように、非常に詳細なセキュリティー用語集を維持管理する必要があります。私は出発点として、Oasis の Security Services TC Glossary から始めるようにお勧めします。すべてのベンダーがこの用語集を共有するようにし、全員の理解を共通にする必要があります。
まとめ
この記事では、SOA セキュリティーのロードマップを作成するための以下の 10 ステップについて学びました。
- 適切なチームを編成する
- 詳細なプロジェクト・プランを作成する
- SOA 対応可能性セキュリティー判定マトリックスを持つ
- 「内部からのセキュリティー」とリスク管理フレームワークの方法を使って暫定案を作成する
- 内部と外部の利害関係者を定義する
- 要件の収集に適したツールを特定し、使用する
- SDLC プロセスに従って SOA セキュリティーを実装する
- 既存のモデルから発見し、学ぶ
- WS-Security 標準に慣れる
- サードパーティー・ベンダーのための標準を開発する
これらの全ステップに従えば、SOA セキュリティーに関して幸先の良いスタートを切ったことになります。
この 3 回シリーズの、今後の記事にご期待ください。このシリーズでは、SOA セキュリティーの実装を成功させる上で SOA セキュリティー・チームに必要な主な項目について解説します。第 1 回はロードマップを取り上げましたが、第 2 回は上位レベルの設計を、第 3 回はテスト・ケースを解説する予定です。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | John Betancourt は、サプライ・チェーンのセキュリティーや大規模 SOA 実装、サイバーセキュリティーなどを専門とする会社、Intelleges の社長兼会長です。 |
記事の評価
| 
