情報セキュリティ技術動向調査

タスクグループ報告書

（2010 年下期）

2011 年 3 月

目次

序 2010年下期の技術動向 - 今日のセキュリティエンジニアリングの話題....................... 1 1 Ruby on Rails とセキュアプログラミング ..................................................................... 3 2 Apache Shiroアプリケーションフレームワーク .......................................................... 12 3 fanotify（filesystem wide access notification） .......................................................... 18 4 暗号鍵管理システム設計のためのフレームワーク ........................................................ 23 5 Personal Data Service................................................................................................... 29 6 DNSSEC展開の動向...................................................................................................... 37 7 RPKIを用いたルーティング・セキュリティの動向 ..................................................... 41 8 OpenFlowによるネットワーク分離 .............................................................................. 44 9 トンネリング技術のセキュリティ上の弊害と IPv6 移行技術における経路ループの危険性 ..................................................................................................................................... 51

1

序 2010 年下期の技術動向 - 今日のセキュリティエンジニアリングの話題

宮川 寧夫

1 背景

情報セキュリティ技術動向調査 TG（タスクグループ）[1]は、その第 6回目の会合を 2010年 12 月 24 日に開催した。情報セキュリティのエンジニアリングの分野において注目すべき動向を発表しあい、発表内容に基づいて討議した。 本報告書は、読者として IT技術者を想定している。IT技術者によるエンジニアリング活動の中で、注目すべき動向もしくは話題を各委員独自の視点から紹介・解説していただい

て本書を取りまとめた。 2 目的

本書は、読者として主に情報処理技術者を想定している。情報技術の「アーリーアドプ

ター（Early Adopters）」や「アーリーマジョリティ（Early Majority）」[2] と呼ばれるような先進的な技術に関心を寄せる読者に、そこで想定されている用途に関する情報を添え

て提供する。これによって、各自もしくは各組織における情報セキュリティに関するエン

ジニアリングの課題の解決に資するものとしたい。 なお、先進的な技術を題材とするため特定の実装を紹介することがあるが、オープンな

仕様が存在している場合、主にその仕様に基づいて解説するように留意している。 3 概況

今期、数あるアプリケーションフレームワークの中にセキュリティエンジニアリングに

活用できるようなものが台頭してきた。脆弱性低減機能やアクセス制御等のセキュリティ

機能を高めつつあるものとして、Ruby on Railsと Apache Shiroを採りあげた。セキュアプログラミングについての専門知識をもたないエンジニアでも、これらのフレームワーク

自体が備えるようになった知識によって一定レベル以上にセキュアなアプリケーションを

開発できるようになることに注目した。 Linux カーネルのファイルシステムへのアクセスを監視・通知する機能については、複数の開発者によるプログラムが競合する懸念があったが、この機能のモジュラリティを確

保する技術として、fanotify（filesystem wide access notification）が整備されたので採りあげる。 暗号技術を利用するシステムにおいて重要な役割を果たす暗号鍵管理システム設計のた

めにフレームワークを示す文書が、米国 NIST（National Institute of Standards and Technology）から発行されたので解説する。

2

アイデンティティ管理技術の動向として、選択的な個人情報の提供を実現するために個

人本人が管理する Personal Data Serviceの動向を概観する。 インターネットインフラストラクチャについては、恒例の RPKI（Resource PKI）を用いたルーティング・セキュリティの動向と、DNSSEC展開の話題を採りあげる。 ネットワーク構築技法における話題として、OpenFlowという次世代ネットワーク制御技術によるネットワーク分離を紹介し、トンネリング技術を利用する際のルーティングルー

プの危険性について IPv6 との関連から解説している。今後、普及させる必要がある IPv6関連のセキュリティ技術動向については注目していく必要がある。 参照

[1] 情報セキュリティ技術動向調査 TG（タスクグループ） http://www.ipa.go.jp/security/outline/committee/isec_tech1.html

[2] ジェフリー･ムーア（著），川又 政治（訳），「ハイテク・マーケティング」『キャズム』，

翔泳社（2002）pp. 11-38

3

1 Ruby on Rails とセキュアプログラミング 長谷川 武

1. Ruby on Rails とは

著名なWebアプリケーションフレームワークのひとつにRuby on Rails がある。Ruby on Rails は、プログラミング言語 Ruby を対象として作られた Web アプリケーションフレームワークである。2004年 7月に初めて登場し、2010年 8月 29日にはバージョン 3が正式リリースされた。[1]

Ruby on Rails は、多くの機能を備えた部類のフレームワークである。主に次の機能を備えている。

Web アプリケーションの基本構造 セッション維持の仕組み HTTP リクエストと処理モジュールのマッピング テンプレートエンジンによる Webページの生成 入力検査の仕組み ユーザ認証とアクセス認可の仕組み ※ データベースアクセス（O/R マッピング[注]等） REST サポート（URLのマッピング） Ajax サポート キャッシュ 等

※ サードパーティから入手できる認証・認可用のプラグインモジュールを追加して実現する。Ruby on Rails はそのための枠組みをもっている。

Ruby on Rails は、Ruby言語がもつ拡張性の高さを利用して作られている。Rubyでは、実行時にクラスの機能を拡張することができる。そのことを利用して、新しい「指令」をいくつも定義し、ひ

とつのクラスをドメイン固有言語（DSL）の処理系として使うことができる。プログラミングの場面では、そのようにして定義された Ruby on Rails 特有の「指令」を多数用いることになる。

2. Ruby on Rails 上のセキュアプログラミング

Ruby on Railsはバージョン 2から、SQL注入等の著名な脆弱性への対応が考慮され始めたと言われている。それは、現在の最新版（バージョン 3）においても引き継がれ、拡充されている。

Ruby on Rails のセキュアプログラミング機能、およびセキュリティの考慮事項には、主に次のものがある。[2][3]

4

* 著名な脆弱性対策 a) SQL注入対策 b) スクリプト注入（XSS）対策 c) リクエスト強要（CSRF）対策

* 入力値対策

d) 入力値検査 e) Taintを利用した入力値追跡

* 計画的なセキュリティ機能性

f) ユーザ認証 g) アクセス認可

これらのうち、(1)～(4) が、Ruby on Rails そのものが備えているものであり、(5)～(7) は、サードパーティによるプラグイン等が提供している機能である。 2.1 SQL 注入対策

Ruby on Rails では（バージョン 2 以降）変数バインディング機能を用いることで、不用意な文字列連結による SQL注入脆弱性の発生を回避できるようになっている。 例

(1) r1 = Persons.all(:conditions => ["name = ?", params[:x]]) (2) r2 = Persons.where("name = ?", params[:x])

上記のうち、(1) がバージョン 2、(2) がバージョン 3のスタイルである。 これらの変数バインディングの実装であるが、Ruby on Rails の中のデータベース・アダプタ・クラスにおいて、それぞれのデータベース・ソフトウェアに応じた特殊文字のエスケープ処理を設ける

ことによって実現されている。データベース・ソフトウェアの prepared statement 機能は利用されていない。 ところで、文字列連結による SQL文の組み立てはAPI の上では禁止されていないので注意が必要である。例えば、次のような書き方は避けるべきである。 避けるべき例

(1) r1 = Persons.all(:conditions => ["name = '#{params[:x]}'"]) (2) r2 = Persons.where("name = '#{params[:x]}'")

5

以前から Ruby on Rails には、ActiveRecord と呼ばれる O/Rマッパーがバンドルされてきたが、Ruby on Rails 3 では、この ActiveRecord にも改造が施された。データベース・クエリに ARel と呼ばれるドメイン固有言語（DSL）が導入されたので ある。

ARel のプログラミングは、従来のように SQL 文全体を一度に記述するのではなく、select, from, where, group といった、SQLの構成要素に対応したメソッドを呼び出して、Relation クラスのインスタンスの上にクエリの条件を追加してゆくスタイルをとる。

ARel の導入で、例えば、次のようなメソッドが追加されている。 (1) Rails 2 までに存在していたメソッド

find, first, last, all, exists?, count_by_sql, find_by_sql, create, update, update_all, delete_all, destroy_all 等

(2) Rails 3 から追加されたメソッド

select, from, where, group, having, includes, joins, limit, order, reorder, create_with, eager_load, preload average, calculate, count, maximum, minimum, sum 等

ARel の導入にともなって増やされたメソッドにおいても、変数バインディングの機能が設けられているので、常にそれを用いることを推奨する。 クエリを断片ごとに記述する ARel のメソッド呼び出しは、見た目は異なっていても、相変わらず

SQL文を操作しているのだという意識をもち、SQL注入脆弱性に用心する必要がある。 2.2 スクリプト注入対策

Ruby on Rails 2 では、出力ページの ERBテンプレート（rhtml ファイル）に例えば次のような記述をすることによって、& " < > の記号にエスケープ処理を施した上で値を出力させることができる。

Rails 2 の例 <%= h @name %>

この h メソッドは、ERB::Util クラスの html_escape メソッドの別名である。 Ruby on Rails 3 では、ERBテンプレートにおける h メソッドの適用がデフォルトになった。

Rails 3 の例 <%= @name %>

6

何も書かなければ、h メソッドによるエスケープ処理が適用される。これに伴い、逆に、このエスケープ処理を敢えて行わせないための raw メソッドが導入された。

Rails 3 の例（推奨はしない） <%= raw @name %>

この h メソッドによるエスケープ処理は多くの箇所で効果を発揮するものの、タグの属性値を出力する際値を必ず引用符で囲む（"..."）配慮が必要である。また、次の箇所では対策効果が無いかまたは弱く、出力値にさらなる制約を設ける必要がある。：

タグの属性値のうち次の箇所 - <img src="...">等のURIを指定可能な属性 - style="..." 属性 - onMouseOver="..." 等のイベントハンドラ属性

<script>...</script>の内側 2.3 リクエスト強要（CSRF）対策

Ruby on Rails ではリクエスト強要（CSRF）対策の、フォームへのトークンの埋め込みとフォームデータを受信した際のトークンの照合が自動で行われる。 2.3.1 トークンの自動埋め込み

form_for 等のメソッドで生成するフォームには、自動でリクエスト強要（CSRF）対策のトークンが自動で埋め込まれる。Rails 2 ではトークンの固定値をプログラマが指定する形態が存在したが、Rails 3 では、処理系がランダムな値を生成するよう変わっている。 例えば、form_for メソッドでフォームを記述すると：

<%= form_for @foo do |f| %> ...

次のように、フォーム内に authenticity_token という名前のトークンが埋め込まれる。： <form action="/foos" class="new_foo" id="new_foo" method="post"> <input name="authenticity_token" type="hidden" value="JWI+bZ1tsj8dhTmBC8ZOV+PYGlfhKQwP2u0b9ehCCcg=" /> ...

7

2.3.2 トークンの自動照合

コントローラクラスのビジネスロジックが呼び出される前に、リクエスト強要（CSRF）対策のトークンの照合が自動で行われる。ただし、照合が行われるのは次のようなHTTPリクエストの場合である。

(1) POSTで送信されるフォームデータに限られる。 (2) protect_from_forgery 指令によって指定されたコントローラクラスとメソッドの範囲。デフォルトの保護対象は、すべてのコントローラクラスの全メソッド（ただし POST で呼ばれるもの）である。

照合が行われ、トークンの値が適切でないと、

ActionController::InvalidAuthenticityToken

という例外が発生し、当該 HTTP リクエストの処理は中断される。 この、リクエスト強要（CSRF）対策のトークン自動照合は、Ruby on Rails が備えている

before_filter という機能を用いて実現されている。この before_filter を用いると、ビジネスロジックと、そのビジネスロジックの呼出をWebクライアントに許すか否かのセキュリティロジックとを分離して配置することが可能である。 所定のセキュリティロジックを配置しておけば、プログラマはビジネスロジックの記述に集中するこ

とができ、また、ソースコードをシンプルに保つことができる。 2.4 入力検査

Ruby on Rails アプリケーションの「モデル」クラス群には、項目ごとの入力値チェックを指定できる validates 指令および validates_xxx 指令群が用意されている。

Ruby on Rails 2 では、例えば、次のような validates_xxx 指令群を用いて入力値検査を指定することができる。

validates_presence_of :name （項目 name の値が空でないこと）

validates_length_of :password, :minimum => 8, :maximum => 20 （項目 password の値が 8桁以上 20桁以下であること）

validates_format_of :email, :with => /¥A[-_.¥w]+@[-¥w]+¥.[-.¥w]+¥z/

8

（項目 email の値が当該正規表現にマッチすること）

validates_inclusion_of :gender, :in => %w( m f ) （項目 gender の値が m または f のみであること）

validates_uniqueness_of :customer_code, :case_sensitive => false （項目 customer_code がDBテーブル中で重複しないこと。大文字小文字は区別せず比較する） 等

Ruby on Rails 3 からは、validates 指令が加わった。ひとつの入力項目の複数の検査仕様を、ひとつの validates 指令を使って記述できるようになった。

validates この validates 指令および validates_xxx 指令群は、アプリケーションの「モデル」部分、すなわち ActiveRecord 継承クラスに記述する。検査は値がデータベースへの格納の前に行われる。 データベースに格納されるデータの仕様への合致は確保できるが、「モデル」のどれかのクラス

のフィールドを、データベースに格納する前に参照し、何らかの形で利用する場合、独自の入力検

査ロジックを書く必要がある。 2.5 Taint 機能

Ruby 言語には Taint 機能が備わっている。Taint 機能とは、オブジェクトにマークをつけ、信頼できない入力値の伝播を追跡できる仕組みである。

Ruby on Rails 自体は Taint 機能を利用していないが、Taint 機能を用いたプラグインをつくることが可能である。

Ruby on Rails 2 用には、Taint 機能を利用したスクリプト注入（XSS）対策プラグインとして SafeERB というものが存在している。 2.6 ユーザ認証

Ruby on Rails 本体には、ユーザ認証の仕組みは用意されていない。しかし、ユーザ認証のための複数のプラグインがサードパーティから提供されている。 サードパーティによるユーザ認証プラグインの例 [4]

Devise Authlogic

9

Restful authentication Clearance Rails OpenID 等

2.7 アクセス認可

Ruby on Rails 本体には、アクセス認可の仕組みは用意されていない。しかし、アクセス認可のための複数のプラグインがサードパーティから提供されている。 2.7.1 所有者やロールによる認可

情報の所有者やロールにもとづくアクセス認可のプラグインには、例えば、CanCan、declarative_authorization、grant 等がある。[5]

コード CanCanの権限記述例

# models/ability.rb

class Ability

include CanCan::Ability

def initialize(user)

user ¦¦= User.new # guest user

if user.role? :admin

can :manage, :all

else

can :read, :all

can :create, Comment

can :update, Comment do ¦comment¦

comment.try(:user) == user ¦¦ user.role?(:moderator)

end

if user.role?(:author)

can :create, Article

can :update, Article do ¦article¦

article.try(:user) == user

end

end

end

10

end

end

出典 http://railscasts.com/episodes/192-authorization-with-cancan

2.7.2 ログインによる保護

未ログイン者からコンテンツを保護するしくみは、ユーザ認証プラグインがサポートしていることが

多い。 2.7.3 before_filter によってコンテンツを保護する

Ruby on Rails アプリケーションの「コントローラ」クラス群（HTTPリクエストに応じた処理を行う）では、before_filter という指令が使える。これは、「コントローラ」クラス群のビジネスロジックが呼び出される前に、何らかのフィルタ処理メソッドの呼び出すよう定義するものである。これを用いると、

ビジネスロジックとアクセス認可のためのコードをきれいに分離して配置できる。ユーザ認証やアク

セス認可のプラグインの多くは、これを利用している。 以上

11

参考文献・参照プロジェクト

[1] "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

[2] Heiko Webers "Ruby on Rails Security Updated" http://www.slideshare.net/heikowebers/ruby-on-rails-security-updated-rails-3-at-railsw

aycon

[3] Heiko Webers "Ruby On Rails Security Guide" http://guides.rubyonrails.org/security.html

[4] 認証プラグインのプロジェクト（主なもの） Device - https://github.com/plataformatec/devise authlogic - https://github.com/binarylogic/authlogic restful-authentication - https://github.com/technoweenie/restful-authentication clearance - https://github.com/thoughtbot/clearance ruby-openid - https://github.com/openid/ruby-openid

[5] 認可プラグイン・プロジェクト CanCan - https://github.com/ryanb/cancan declarative_authorization - https://github.com/stffn/declarative_authorization grant - https://github.com/nearinfinity/grant

参考資料

木村，「Ruby On Rails Security Guide の訳 : 概要 + 1.Introduction」

http://www.flatz.jp/archives/1942

松田明 ，「Rails 3 を支える名脇役たち その 1 - Arel -」

http://gihyo.jp/dev/serial/01/ruby/0043

「Ruby リファレンスマニュアル - ERB クラス」

http://www.ruby-lang.org/ja/man/html/erb.html

12

2 Apache Shiro アプリケーションフレームワーク

宮川 寧夫 1. 今日の Web アプリケーションフレームワーク

Webアプリケーションフレームワークは、文字通り、Webアプリケーション開発の枠組みを与えるものであり、そのまま動作環境となる。その備える機能の程度には差がある。

CMS（Contents Management System）として機能するものもある。また、最近のフレームワークとしての特徴として、REST（Representational State Transfer ）[1]と呼ばれる設計方針や、MVC モデルをサポートしようとしているものがある。MVC モデルとは、コンポーネントの役割を「Model」、「View」および「Controller」の 3つに分けてアプリケーションを設計手法である。 数あるWebアプリケーションフレームワークの中から、今回、Apache Shiro [2]（以下、

Shiro）というオープンソース Web アプリケーションフレームワークを今期の話題として採りあげる。その理由は、Shiroが今期、2010年 9月に ASF（Apache Software Foundation）におけるトップレベルプロジェクトに昇格したことにある。その後、11 月 3 日にはバージョン 1.1.0リリースされた。この Shiroは、本人認証、リソースへのアクセス認可、暗号技術的処理等のセキュリティ機能を請け負うことに特化しており、REST の設計方針も採用しているが、MVCモデルは採用していない。 2. Shiro に至る系譜

Shiro プロジェクトの発足当時の名前は、今日とは違い、2004 年時点では JSecurity というプロジェクトであった。これは、Sun （現 Oracle）純正の JAAS （Java Authentication and Authorization Service ）というライブラリの難点であった使い難さを解消するために、使い易いインタフェイスとなるように薄皮を被せたAPI ライブラリのようなものであった。JSecurity プロジェクトは、その後、ASF（Apache Software Foundation）に加わった。ASF においては、トップレベルプロジェクトに育成されるインキュベータープログラム（Incubator Program）に応募して採択された。JSecurity は、その後、いったん Kiと改名されたが、すぐに再度、Shiroと改名された。 そして、上述のように Shiro のバージョン 1.0 が 2010 年７月にリリースされ、同年 9月には ASFにおけるトップレベルプロジェクトに昇格した。 3. Shiro のセキュリティ機能

Shiro内のセキュリティマネージャが管理する機能には、次の 4つがある。

13

本人認証 リソースアクセス認可 セッション管理 キャッシュ管理 また、暗号技術的処理の機能は、APIライブラリとして独立している。

図：Shiroのセキュリティ機能

（出典：http://shiro.apache.org/architecture.html） 3. Shiro の特徴

Shiro は、今日的な REST の設計方針に対応していると共に、下記の特徴をもつと主張されている[3]。これらの中からも読み取ることができるように、Webアプリケーションの形態とならないスタンドアロンのシステムの開発も行うことができるフレームワークとな

っている。

(1) 理解し易い Java Security API クラス名やインタフェイス名は、直感的であるとともに合理的である。併せて、

デフォルト設定も良く整えられている。 (2) シンプルな本人認証（authentication）

LDAP、JDBC、Kerberos、Active Directory等のユーザデータの源泉と簡単につ

14

なぐことができる。 (3) シンプルなアクセス認可（authorization）

役割（role）と、詳細なパーミッション（permission）の設定をもつ。また、上記のように、容易につなぐことができるユーザデータの源泉を使うことができる。

(4) 高度なキャッシュ機能 アプリケーション性能を高めるために、最高水準のキャッシュ機能を備えている。

(5) 組み込まれた Plain Old Java Objectに基づくセッション管理 Webと非Web環境の両方において POJO（Plain Old Java Object）使う。セッシ

ョン管理は、SSO（Single Sign On）や、クラスタ構成の複数サーバにまたがるセッションや、分散された複数のサーバ群にまたがるセッションを必要とするような、

あらゆる環境において使えるものとなっている。 (6) 多様なクライアントとのセッション

従来の HttpSessionや Stateful Session Beansは、しばしば不必要にアプリケーションを特定の環境に拘束してきたが、これらのみを使う必要は無くなっている。

Flash アプレット、C#アプリケーション、 Java Web Start 等、多様な（Heterogeneous）クライアントが、開発環境に依存せずにセッション状態を共有できるようになっている。

(7) シンプルな Single Sign On 上記のセッション管理を利活用して、セッションが複数のアプリケーションに跨

って実装されている場合、ユーザ認証（authentication）の状態も共有できる。あるアプリケーションへのログインが、別のアプリケーションにも認識できるようにな

っている。 (8) 可能な限りシンプルな暗号技術 API

暗号とハッシュ機能について、JCE（Java Cryptography Extensions）の複雑さを隠喩して容易に使えるようになっている。

(9) 堅牢でありながら設定が容易なWebフレームワーク あらゆる URLもしくはリソースをセキュアにすることができ、loginと logoutを

自動的に扱えて、Remember Meサービスも行う。 (10) 極めて少ない依存関係

スタンドアロン設定の場合、slf4j-api.jar と slf4jの binding.jarの中のひとつしか要求しない。Web 設定の場合も、commons-beanutils-core.jar を追加的に要求するのみである。また、機能追加（例：Ehcache [4]によるキャッシュ機能、Quartz [5]に基づくセッション検証機能、Spring フレームワークとの統合（後述）等）に応じて少数の依存関係を考慮することになる。

15

4. 開発環境の構成方法

卑近な Java開発環境にShiro以外にはDependency MangerとしてMavenもしくは Ivyを追加的にインストールする必要がある。 従来の APIライブラリを呼び出すように Shiroを使って開発することができるが、今日では、親和性のある他のアプリケーションフレームワークで開発されたアプリケーション

を Shiro に対応させるような使い方もできるようである。本稿では、後者の用法に着目する。具体的には、「Spring Application Framework（以下、Spring）」[6]で開発されたアプリケーションや、Grails [7]で開発されたWebアプリケーションが Shiroに統合できるようになっている。Shiro には「HTTP フィルタ」と呼ばれる機能が用意されており、これを利用すると、Shiroに含まれているアプリケーションのセキュリティ機能を利用できるようになる。 5. 「HTTP フィルタ」を介する統合

統合における連携は、javaサーブレットが利用するweb.xmlファイルを介して行われる。web.xmlファイルは、「サーブレットデプロイメントデスクリプター（Servlet deployment descriptor：配備記述子）と呼ばれ、JavaのWebアプリケーションの設定を書くファイルである。Shiroが他のフレームワークと統合できる条件は、Shiroとのインタフェイスがこのファイルに集約されていることであり、依存関係を極めて少なくすることができている

要因でもある。Springや Grailsには web.xmlを適宜、編集・更新する機能があり、Shiroに制御を移す部分が記述される。

web.xmlファイルにフィルタが追記された設定のサンプルを掲げる。

<!-- The filter-name matches name of a 'shiroFilter' bean inside

applicationContext.xml -->

<filter>

<filter-name>shiroFilter</filter-name>

<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>

<init-param>

<param-name>targetFilterLifecycle</param-name>

<param-value>true</param-value>

</init-param>

</filter>

...

<!-- Make sure any request you want accessible to Shiro is filtered. /* catches all

16

-->

<!-- requests. Usually this filter mapping is defined first (before all others) to

-->

<!-- ensure that Shiro works in subsequent filters in the filter chain:

-->

<filter-mapping>

<filter-name>shiroFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

（出典：http://shiro.apache.org/spring.html）

6. まとめ

Shiroは、本人認証機能やリソースへのアクセス認可等のセキュリティ機能に特化したフレームワークであり、Web アプリケーションのみならず、スタンドアロンシステムも開発できる。Shiro について注目されるのは、従来の API ライブラリを呼び出すような開発にも利用できると共に、依存関係が少ない利点を活かして他のアプリケーションフレームワ

ークで開発されたアプリケーションに「HTTP フィルタ」を介してセキュリティ機能を統合するような開発にも活用することができるようになったことにある。

以上

17

参考文献・参照プロジェクト

[1] Roy Thomas Fielding, `CHAPTER 5 Representational State Transfer (REST)’ “Architectural Styles and the Design of Network-based Software Architectures” (2000)

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm [2] APACHE SHIRO

http://shiro.apache.org/ [3] `Apache Shiro Features Overview’

http://shiro.apache.org/features.html [4] Ehcache - The Most Widely Used Java Cache

http://ehcache.org/ [5] Quartz - Enterprise Job Scheduler

http://www.quartz-scheduler.org/ [6] sprigngsource community

http://www.springsource.org/ [7] GRAILS

http://grails.org/ 参考資料

Bruce Phillips, An Introduction to Shiro (formerly JSecurity) A Beginner’s Tutorial

- Part 1 http://www.brucephillips.name/blog/index.cfm/2009/4/5/An-Introduction-to-Ki-formerly-JSecurity--A-Beginners--Tutorial-Part-1

- Part 2 http://www.brucephillips.name/blog/index.cfm/2009/4/5/An-Introduction-to-Ki-formerly-JSecurity--A-Beginners--Tutorial-Part-2

IBM developerWorks Japan,「Apache Shiroの紹介」 http://www.ibm.com/developerworks/jp/web/library/wa-apacheshiro/index.html

18

3 fanotify（filesystem wide access notification）

面 和毅

fanotifyは、Linux 2.6.36カーネルから取り込まれたファイルシステムの状態変化を通知する機構である。まず、他の通知機構である dnotify/inotify や fsnotify との関係性をみてみよう。 1. dnotify/inotify について

ファイルシステムの状態変化を通知する機構に関しては、Linux でも古くから実装が行われてきた。例えば、dnotifyという 2.4.19カーネル以降でメインラインに取り込まれた機構があり、これはディレクトリの状態変化を通知する機構である。この実装により、例え

ば、/etc以下のファイルが更新されているなど、設定ファイルの更新を記録することも可能であり、セキュリティ上でもディレクトリ内のファイルの勝手な更新を記録できるなどの

効果があった。 更に 2.6.13カーネルからマージされた inotify（inode-based file event notifications）では、dnotify がディレクトリ単位での通知しか行えない機構であるのに対し、inode ベースでファイルの追加／変更／削除などのイベントを通知してくれる機構となった。inotify では、更に dnotifyに比べて

ディレクトリの状態変化を監視できる リムーバブル・メディアの監視に対応している dnotify ではファイルディスクリプタが監視対象ディレクトリ毎に必要だったが、

inotifyではひとつだけとなり、コストが下がっている ものとなっており、更にファイルシステム上の状態変化を細かく通知してくれるため、セ

キュリティ上のより細かい記録が取れるようになった。また、SELinux など、inode が更新された都度、ラベル情報を更新しなくてはならないアクセス制御システムでは、inotifyを利用して inodeの更新情報を取得する事ができるようになった。（ただし、inotifyではアクセスを行った主体に関する情報が取得できないため、監査で使用するには別途アクセス

制御機構のログと組み合わせる必要がある。） inotify は、後述する fsnotify が 2.6.31カーネルから取り込まれたため、fsnotify の機構を利用した上位レイヤで動く機構としてコードが更新された。2.6.36 カーネル内部からはカーネル内で実装する必要が無いとされ、userspaceの interfaceは 2.6.36以降でもサポートされているが、inotify自体のコードは 2.6.36カーネル内部からは削除されている。

19

2. fsnotify とは

fsnotifyは、filesystem上でのイベント通知機構のバックエンドとなる機構であり、今までの通知機構の実装をシンプルにするために導入された。fsnotify自身は、userspaceへのインターフェースを持っておらず、dnotify, inotify, fanotifyなどの通知機構のための基盤となっている。2.6.31以降、inotify/dnotifyは fsnotifyを利用するレイヤとしてシンプルに書き直された。

fsnotify により、inode 構造体のサイズが最適化されている。fsnotify が導入される以前の inode構造体には

unsigned long struct dnotify_struct struct list_head struct mutex

i_dnotify_mask; /* Directory notify events */ *i_dnotify; /* for directory notifications */ inotify_watches; /* watches on this inode */ inotify_mutex; /* protects the watches list

がメンバとなっていたが、fsnotifyの導入により、

__u32 struct hlist_head

i_fsnotify_mask; /* all events for this inode */ i_fsnotify_mark_entries; /* marks on this inode */

というようにメンバの数が少なくなっている。 3. fanotify とは

fanotify は inotify など他の通知機構と同様に、2.6.31 カーネルから取り込まれているfsnotifyの上位レイヤで動く機構として実装されている。fanotifyは、ファイルディスクリプタをオブジェクトに対してオープンした際に（open, close, read, write）という発生イベントの種類をユーザスペースに通知する為の機構であり、新たに実装された機構である。

当然この機構は、他の通知機構（inotify や dnotify など）と競合を起こす可能性があるため、他の通知機構をブロックしたり制御できるように実装される予定となっている。 この fanotifyは主に Anti Virusソフトベンダやシステム監査ソフトベンダが利用する為に実装された。 4. 今までの Anti Virus ベンダでの実装

Anti Virusベンダでは、オブジェクトを open/closeしたイベントを掴んでウィルスエンジンに渡すために、syscall tableのアドレスをコピーして上書きするなど、かなり荒っぽいやり方で独自の通知機構を実装してきた。 このような方法は概ねうまくいっているが、同様の機構（ファイルシステムに何かイベ

20

ントが発生した際の通知機構）を利用するアプリケーションを、同一サーバ上で使用して

いる場合には、問題が生じてくる。例えば、Software Aと Software Bが同様に syscall tableのアドレスをコピーして上書きしていた場合には、ソフトウェアの起動と停止を、起動順

に行っていくと Syscall Table（Syscall_Tableとする）が

Software Aを起動 Software Bを起動 Software Bを停止 Software Aを停止

→ → → →

Syscall_Table_A（Software Aが Syscall Tableを上書き） Syscall_Table_A_B （Software Bが Syscall Tableを更に上書き） Syscall_Table_A （Software Bが Syscall Tableを開放し、自身が起動する直前の物に上書き） Syscall_Table

となるため特に問題は生じないが、システムの運用上の理由など、なんらかの理由で停止

順序が狂い、Software Aを先に停止してしまった場合には

Software Aを起動 Software Bを起動 Software Aを停止

→ → →

Syscall_Table_A （Software AがSyscall Tableを上書き） Syscall_Table_A_B （Software Bが Syscall Tableを更に上書き） Syscall_Table （Software Aが Syscall Tableを開放し、自身が起動する直前の物に上書き）

となり、Software Bが上書きしていた Syscall_Tableではなく、最初の Syscall_Tableに戻ってしまうため、Software Aや Software Bがクラッシュしてしまうことがあった。 このような、ファイルシステムにイベントが発生した際に何かを行う機構は、Anti Virusの他にも、システム監査の目的でアクセスログを取得するようなソフトウェアが使用して

いるケースが多い。そのようなソフトウェアがインストールされるシステムでは、セキュ

リティの観点上、Anti Virus ソフトウェアもインストールされているケースが多いため、実運用の際に上述のようなトラブルになるケースが起きていた。 5. fanotify を利用した場合

2.6.36以降のカーネルを使用しているシステムでは、fanotifyとして通知機構が取り込まれているため、イベントの通知機構を各社独自で実装する必要はない。カーネルにそもそ

も取りこまれている fanotify をベースとしてイベントを掴むようになるため、前述のよう

21

なトラブルも起きることは無く、実運用上でより安定したシステムが提供されることにな

る。 6. fanotify のサンプル

fanotifyを用いてユーザ空間にイベントを通知させるサンプルコードは、 git://git.kernel.org/pub/scm/linux/kernel/git/agruen/fanotify-example.git から取得できる。 上記サンプルコードの使い方だが、コンパイルは git でダウンロードした際にできる

"fanotify-example"ディレクトリ内で一般ユーザで"make"とすれば

omo@localhost:̃/work/fanotify-example$ make

cc -g -Wall -Wextra -O2 -Iinclude -D_GNU_SOURCE -c -o fanotify.o fanotify.c

cc -g -Wall -Wextra -O2 -Iinclude -D_GNU_SOURCE -c -o fanotify-syscalllib.o

fanotify-syscalllib.c

cc -g -Wall -Wextra -O2 fanotify.o fanotify-syscalllib.o -o fanotify

omo@localhost:̃/work/fanotify-example$

となって fanotifyバイナリが作成される。このバイナリだが、rootユーザでのみ実行でき、ディレクトリ内のファイル／サブディレクトリに、どの PID のプロセスがどのようなアクセスを行ったかを表示する。具体的なヘルプは、fanotify -hで見ることができ、

omo@localhost:̃/work/fanotify-example$ ./fanotify -help

USAGE: ./fanotify [-cfhmn] [-o

{open,close,access,modify,open_perm,access_perm}] file ...

-c: learn about events on children of a directory (not decendants)

-f: set premptive ignores (go faster)

-h: this help screen

-m: place mark on the whole mount point, not just the inode

-n: do not ignore repeated permission checks

-s N: sleep N seconds before replying to perm events

となっている。 例えば、

root@localhost:/home/omo/work/fanotify-example# ./fanotify -c /tmp

22

としてから、別のプロセスで/tmpディレクトリ以下にアクセスすると

/tmp: pid=1519 open ← /tmp ディレクトリを ls した場合

/tmp: pid=1519 close

/tmp/test: pid=1521 open ← /tmp/test サブディレクトリを lsした場合

/tmp/test: pid=1521 close

/tmp/test123: pid=1523 open close(writable) ← /tmp/test123 としてファイルを

touch した場合

/tmp/test123: pid=1524 close ← /tmp/test123 を vi で編集した場合

/tmp/.test123.swp: pid=1524 modify として、/tmpディレクトリ以下に行われたイベントが記載されていく。pid/user との対比は、別途 psコマンドなどで取得した情報を元に行う。例えば、上記 fanotifyコマンドを実行している間に、別セッションで"pstree -pu > /tmp/pstree_pu"とすると

/tmp/pstree_pu: pid=1598 open

/tmp/pstree_pu: pid=1598 modify

/tmp/pstree_pu: pid=1598 close(writable) のように出力される。このときの pstreeコマンドの実行結果（/tmp/pstree_puファイルの中身）は、

init(1)-+-acpid(973)

¦-sshd(1374)-+-sshd(1392)---sshd(1394,omo)---bash(1395)---su(1424,root)--

-bash(1425)---fanotify(1597)

¦

`-sshd(1485)---sshd(1488,omo)---bash(1489)---su(1570,root)---bash(1571)--

-pstree(1598)

`-udevd(301)-+-udevd(524)

`-udevd(525) となっており、pid1598の親プロセスのUIDが rootであり、さらに元の親が UID omoで実行されていることがわかる。

以上

23

4 暗号鍵管理システム設計のためのフレームワーク

金岡 晃 1. 暗号鍵管理に関する動向

暗号鍵の管理に関しては、米国国立標準技術研究所（NIST）が 2005年に SP（Special Publication）シリーズとして SP 800-57 "Recommendation for Key Management"の Part 1を発行し、暗号鍵管理の全体像を示した。その後 Part 1は 2回、改訂を繰り返し、最新のものは 2007年に改訂された。また Part 2、Part 3も発行されて、ベストプラクティスや特定アプリケーションでの鍵管理を述べている[1]。 暗号鍵の管理は、単に暗号鍵の保護機構のみならず、暗号鍵の種類や有効期間・強度な

ど暗号鍵そのものに関する情報や、暗号鍵の確立や保護、保証、アーカイブ、バックアッ

プなど暗号鍵の管理機能、さらに管理フェーズや暗号鍵の状態、移行など暗号鍵の運用を

含んでおり、非常に多岐にわたる。 国内では、「安全な暗号鍵のライフサイクルマネージメントに関する調査」が IPAにより行われ、2008年 7月にその報告書が公開されている[2]。報告書ではNIST SP 800-57だけでなく、ISO/IECや IETF（Internet Engineering Task-Force）に関する動向にも触れられている。 今期は、NISTが複数の暗号鍵管理関連の文書を公開した。まず2010年6月にSP 800-130

"A Fremework for Designing Cryptographic Key Management Systems"のドラフトが公開され[3]、続いて SP 800-131 "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths"がドラフト公開の後 2011年 1月に正式発行[4]、2010年 12月に SP 800-132 "Recommendation for Password-Based Key Derivation Part 1: Storage Applications"[5] 、 SP800-135 "Recommendation for Existing Application-Specific Key Derivation Functions"[6]がそれぞれ発行されるなど、活発な動きを見せている。 国内では、2010年 11月 22日に日本ネットワークセキュリティ協会（JNSA）標準化部会において「鍵管理勉強会」が行われるなどの動きもあった[7]。 本稿では多岐にわたる暗号鍵の管理において、さらに広く管理システムの設計フレーム

ワークを述べた SP 800-130 について、これまでの暗号鍵管理に関する文書である SP 800-57との違いを中心に解説し、また SP 800-130に関連して NISTで開催された暗号鍵管理ワークショップ（Cryptographic Key Management Workshop）の紹介を行う。 2. DRAFT SP 800-130 " A Framework for Designing Cryptographic Key Management

Systems"

暗号鍵の管理は SP 800-57に書かれているが、実際の鍵管理を行うシステムをいかに設

24

計するかについて書かれたものが SP 800-130である。SP 800-130は暗号鍵管理システムの設計のためのフレームワークであり、コンポーネントと要件から構成されている。文書

はそのコンポーネントごとに書かれ、それぞれの要件はコンポーネントごとに示されてい

る。システム設計者はこれらコンポーネント群から必要なものを抽出し、設計を行うこと

が可能である。フレームワーク中からいくつかのコンポーネントを選択したサブセットを

「プロファイル」と呼ぶ。NISTでは SP 800-130に加え、米国政府機関向けのプロファイルを作成する予定であるとしている。コンポーネントには下記のものがある。

設計目的（Goals） セキュリティポリシ（Security Policies） 役割と責任（Roles and Responsibilities） 暗号鍵とメタデータ（Cryptographic Keys and Metadata） 暗号鍵管理システムの相互運用性と移行の要件（Interoperability and Transition

Requirements for CKMS） セキュリティ制御（Security Controls） 試験とシステム保証（Testing and System Assurances） ディザスタリカバリ（Disaster Recovery） セキュリティ監査（Security Assessment） 他の検討事項（Other Considerations）

図 1：暗号鍵管理システムの設計のためのフレームワーク

これらのほとんどは SP 800-57が対象としていないものとなっているが、「暗号鍵とメタデータ」部分では SP 800-57と関連する事項が記載されている。それらの差について次項以降で解説する。

25

3. 暗号鍵とメタデータ

暗号鍵はその用途と方式により複数の種類に分けられ、SP 800-57 Part 1では 19種類の暗号鍵を挙げていた。暗号鍵の管理システムを考慮する場合、これら鍵の種類だけでなく

その鍵の識別情報やフォーマット情報、発行日時など鍵に付随する情報を扱うことが必要

となる。SP 800-130ではそういった暗号鍵の利用をコントロールするためのデータを暗号鍵のメタデータと定義している。メタデータとして扱われる情報には以下のものがある。

鍵ラベル 鍵長 親鍵

鍵識別子 鍵強度 鍵の保護

鍵ライフサイクル状

態 鍵タイプ メタデータ保護

鍵フォーマット仕様 鍵の適切なアプリケーション

メタデータ紐付の保護

鍵生成に利用された

製品 鍵に適用可能なセキュ

リティポリシ 日時

鍵を利用する暗号ア

ルゴリズム 所有鍵識別子 失効理由

運用モード 鍵アクセス管理リスト

（ACL）

鍵のパラメータ バージョン番号

4. 暗号鍵の状態と遷移

暗号鍵の状態とその遷移図については SP 800-57でも記載されていたが、SP 800-130ではこれらにシステムでの管理を踏まえた追加として「一時停止（Suspended）」と「失効（Revoked）」の 2つの状態が追加された。

図 2：暗号鍵の状態とその遷移図

26

5. フレームワークに関する議論

SP 800-130のドラフト文書は公開とともにパブリックコメントの募集が行われた。また2010年の 9月にはNISTにおいてNIST Cryptographic Key Management Workshop 2010が開催され、鍵管理についての議論が SP 800-130を中心に行われた[8]。 パブリックコメントは非常に多岐にわたるが、一部コメントを抜粋して紹介する。

文書のミッションとユーザコミュニティはよりよく定義されるべき ID管理システムの要件提示が必要 クラウドコンピューティングモデルの提示が必要 他の文書（SP 800-57、DHS Cyber-security Roadmap、IEC 61509等）との一致 信頼できる時刻情報源についての記載 タイムゾーンの管理の記載 ハードウェアセキュリティモジュール（HSM）による(n,k)分割についての記載 システムへの DoS攻撃対策 安全性（Safety）と Fuzzテスト セキュリティ設定共通化手順（SCAP）の利用

ワークショップでは SP 800-130とそのパブリックコメントの紹介が行われると同時に、米国政府機関アプリケーションに対する暗号鍵管理プロファイルの概要についての発表も

行われた。また参加者間で議論を行う Breakoutセッションが設けられた。Breakoutセッションはフレームワークとプロファイルの 2つに分かれて議論が行われた。 フレームワークセッションではその内容についての議論が行われ、理解を深めるための

より多くの図表の提示や、優先度の高いコア機能の提示、フレームワークとプロファイル

の明確な区別などがまとめとして挙げられた。 プロファイルセッションではその必要性とスコープや粒度、互換性・相互運用性の記載

などの議論が行われた。その結果、そのプロファイルが鍵用途のシナリオに基づいて作ら

れる必要性や、より根本的なプロファイルのスコープや構成・適合性についてより深い議

論が必要であることや、その利用法についての議論が行われたことが報告された。 6. まとめ

暗号鍵の管理は、ますます重要性を帯びている。暗号鍵の管理は、鍵そのものを越えて

管理するシステムを考慮する必要性の存在が SP 800-130策定の大きな背景であろう。そして公開された SP 800-130のドラフト文書の内容とそれを受けてのパブリックコメント、また暗号鍵管理ワークショップでの内容を考慮すると、暗号の鍵管理はその管理システムの

考慮を越えて、さらに暗号鍵を利用するエンティティの管理や時刻情報の管理、そして利

用されるアプリケーションシステムの管理など、鍵管理だけで独立する問題でなく利用シ

ステムや環境の管理を十分に考慮した管理がされなければならず、またシステム自体の安

27

全性管理なども必要となり、その検討事項は多岐にわたることが見えてきた。 暗号鍵管理システムの設計としてどこまでを行うべきかの議論はまだ収束しておらず、

さらに時間を要することも考えられるが、暗号により守られるシステムの強度は鍵自体の

セキュリティ強度のみならず鍵管理の適切さが重要であり、この議論は欠かせるものでは

ない。暗号鍵の鍵管理は今後とも注目が必要なテーマであろう。 以上

28

参考文献

[1] NIST Special Publications (800 Series)

http://csrc.nist.gov/publications/PubsSPs.html [2] 情報処理推進機構，「安全な暗号鍵のライフサイクルマネージメントに関する調査 調

査報告書」，2008年 7月 http://www.ipa.go.jp/security/fy19/reports/Key_Management/documents/keymanagement_report.pdf

[3] NIST SP 800-130, "DRAFT A Framework for Designing Cryptographic Key

Managemet Systems" , June 2010 http://csrc.nist.gov/publications/drafts/800-130/draft-sp800-130_june2010.pdf

[4] NIST SP 800-131 "Transitions: Recommendation for Transitioning the Use of

Cryptographic Algorithms and Key Lengths", Jan. 2011 http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf

[5] NIST SP 800-132 "Recommendation for Password-Based Key Derivation Part 1:

Storage Applications", Dec. 2010 http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf

[6] NIST SP800-135 "Recommendation for Existing Application-Specific Key

Derivation Functions", Dec. 2010 http://csrc.nist.gov/publications/nistpubs/800-135/sp800-135.pdf

[7] 日本ネットワークセキュリティ協会，「鍵管理勉強会」，2010年 11月

http://www.jnsa.org/result/2010/101122seckey/index.html [8] NIST, Cryptographic Key Management Workshop 2010, Sep. 2010

http://www.nist.gov/itl/csd/ct/ckm_workshop_2010.cfm

29

5 Personal Data Service

工藤 達雄 1. はじめに

本報告では 2010 年下半期のアイデンティティ管理技術に関する動向として、PDS（Personal Data Service）の動きを概観する。 2. Personal Data Service とは

個人情報（本人の属性情報のみならず、興味や、所属、友人関係、行動履歴など）のサ

ービス間での流通のありかたについては、従来より、さまざまな場において議論されてい

ることは言うまでもない。その中でも、ユーザ中心の個人情報活用について現在活発な活

動を行っているコミュニティのひとつが、ハーバード大学法科大学院バークマン・センタ

ーのProjectVRMプロジェクト[1]を中心とするVRM（Vendor Relationship Management）コミュニティである。

VRMが目指すものは、いわゆる CRM（Customer Relationship Management）とは逆の、個人によるベンダー（製品やサービスを提供する企業・組織）との関係管理である。

具体的にはベンダーに対する選択的な個人情報の提供や、ベンダーへの提案依頼（パーソ

ナル RFP（Request for Proposal））を行うためのツールなどを提供することによる、ベンダーに対する個人のエンパワーメントを目的としている。 「選択的な個人情報の提供」を実現するためには、当人が把握している個人情報だけで

はなく、本人が預り知らない場所に保管され、本人が知らない用途に利用されてしまって

いる個人情報も含めて、個人本人が管理するためのしくみが必要となる。このしくみを PDS（Personal Data Service）と呼ぶ。（実際には VRMコミュニティの中でも正式名称が確定しておらず、Serviceの代わりに Store、Locker、Vault、Brokerなどの単語が用いられることも少なくないが、本稿では Serviceに統一する。） 3. PDS の機能

PDSは、それ自身が個人情報を一元的に格納するのではなく、PDSの外に存在するさまざまなサービスが保有する個人情報の管理機能を、ユーザに提供する。有力な PDS実装のひとつである Higgins Personal Data Service（詳細は後述）では、PDSの機能を以下のように定義している[2]。

コントロール PDS が提供するのは、個人に関する情報へのアクセスの集中管理機能である。ユーザは PDSを用いて、個人情報を提供するサービスと、その情報を利用するサービスと

30

の間での、データのフローをコントロールする。データはサービス同士が直接やりと

りする場合も、PDSが仲介する場合もある。また、PDS自身が個人情報の提供元となる場合もある。

データ管理 データを PDSが仲介する場合や、PDSがそもそものデータの起点となる場合には、

PDS がデータの正規化を行うことが考えられる。また同時に、流れるデータの内容の確認・記録や、場合によってはその値を変更・更新することも可能となる。

ディスカバリ PDSはディスカバリAPIを提供し、他のユーザや組織、アプリケーションなどから、ユーザに関する問い合わせを受けつける。またそのリクエストがユーザの指定する条

件に合致した場合に、データを提供する。

相互運用性 PDSはさまざまな形態によって運用され、相互に連携し個人情報を交換する。PDSの運用主体は、個人に委託を受けた組織や、個人自身となることが想定される。

4. 現在の状況

2010年後半以降、PDSの概念を実装したソフトウェアやサービスが、いくつか登場している。 4.1 Higgins Personal Data Service

Higgins[3]は、Eclipse Foundation にて開発が進められているオープンソースのアイデンティティ・フレームワークである。現在バージョン 1.1の実装が進められると同時に、次期バージョンとなる 2.0の開発が始まっている。

Personal Data Service（以下Higgins PDS）は同 2.0の構成要素のひとつであり、さまざまなデータソース（例えばソーシャルネットワーク、通信事業者、医療機関など）の情

報を仮想的に統合し、それらに格納されているデータのダッシュボードをクライアント（ブ

ラウザ、デスクトップアプリケーション、モバイルアプリケーションなど）に提供する。

また Higgins PDSの自己情報コントロール機能により、ユーザはデータのサブセットを作成し、自身が信頼する人々や組織に対し提供することができるようになる。

Higgins PDSの、ユーザ向けのWebアプリケーションが「オンライン・プロファイル・マネージャ」である。このWebアプリケーションはユーザに対し、ユーザ自身のデータの統合的なビューや、ユーザ自身がオーソリテイティブ・ソースとなるデータの更新、外部

のユーザやサービスからのアクセス認可管理、サードパーティにアクセスを許可する際の

31

ポリシー定義などの機能を提供する。一方外部のユーザや組織、アプリケーションに対し

ては、Higgins PDSはディスカバリ APIや、OpenID, SAML, InfoCardなどのプロトコルによってアクセス可能なアイデンティティ・プロバイダ・エンドポイントを提供する。

Higgins PDSの周辺には、いくつかのコンポーネントが定義されている（図）。

図：Higgins PDSと他のコンポーネントとの関係

（出典： http://wiki.eclipse.org/Personal_Data_Service_Overview） まず Attribute Data Serviceは、複数のストレージ（Higgins PDS内部に加え、サービス事業者、Web サイト、ソーシャルネットワークなど）に存在する情報を共通のデータモデルにマップし、用途に応じた個人情報のセット（「ペルソナ」）や、そのペルソナと別の

ユーザのペルソナとのリンクなどを管理するサービスである。 次に Higgins PDSを利用するサードパーティ・アプリケーションとして、データ交換アプリケーション（他の人々や組織との個人情報の交換）や、データ・リファイナリー・ア

32

プリケーション（データ精製： Higgins PDS のデータセットを読み出し、解析、セグメンテーションなどを行い、結果を Higgins PDSのユーザに提供）などが想定されている。

Higgins PDSはWebアプリケーションの他に、Active Clientsをユーザに提供する。ユーザは Active Clientsをデスクトップ環境やモバイル環境にインストールすることにより、データ取り込み（ブラウザとの統合による、ユーザがフォームに入力したデータ等のキャ

プチャなど）や、Webオーグメンテーション（Webページにおける、コンテクストに応じた付加情報の表示や、自動フォーム入力など）が可能となる。 4.2 Project Danube

2010年 10月に公開された Project Danube[4]は、PDS を構築するためのオープンソース・ソフトウェア・コンポーネント群である。データ交換のコアに XRI Data Interchange（XDI）[5]を、そのデータ交換に関するアクセス認可に OAuth 2.0[6]を用いている。 以下は OAuth 2.0 のアクセス・トークン（ "68aa..."）を用いて、ユーザ（"=!91F2.8153.F600.AE24"）の属性情報（"$+city", "$+name", ...）をリクエストする XDIメッセージの例である[7]。

[$

[$oauth

["68aa71ca5002f6c47081a8676f551"]

]

[$get

[

[=!91F2.8153.F600.AE24

[$+city]

[$+country]

[$+name]

[$+postal.code]

[$+street]

]

]

]

]

これに対する XDIレスポンスは以下の通り。

33

[=!91F2.8153.F600.AE24

[$+city

["Vienna"]

]

[$+name

["Markus Sabadello"]

]

[$+country

["Austria"]

]

[$+street

["Haasgasse 7¥/13"]

]

[$+postal.code

["1020"]

]

] また Federated Social Web を志向し、WebFinger, LRDD, Atom, ActivityStreams,

PubsubHubbub, Salmon, Portable Contactsなどの、OStatus仕様に定められたプロトコルを実装している[8]。これにより、OStatusに対応したサービスやアプリケーション（例： Status.net、Cliqset）との相互運用が可能となっている[9]。 4.3 Mydex Community Prototype

MCP（Mydex Community Prototype） [10]は、英国 Mydex Community Interest Companyが地域住民向けの個人情報管理サービスの検証を目的に、2010年 10月に運用を開始した PDSである。同システムはHiggins PDSをベースに構築されている。 検証には実際の公共セクターや民間セクターが関わっている[11]。MCPは、リライング・パーティである英国の地方自治体（クロイドン・カウンシル、ブレント区、ウィンザー・

メイドンヘッド市）および中央省庁（労働年金省）に対し、個人情報を提供する役割を担

う。またMCPは Experian社とも連携することにより、ユーザはリライング・パーティとのやりとりに際し、同社の提供する本人確認サービスを利用することも可能となっている。

さらには、MCP が地方自治体に個人情報を提供するだけではなく、逆に地方自治体からMCPに対してデータを送付することも検討されている。

MCPは現時点ではプロトタイプという位置づけであるが、将来的には実サービス化される予定である。

34

4.4 Project Neck Pain

米国 Kynetx社[12]は 2010年 8月に Project Neck Pain[13]を公開した。これは同社の提供するサービスを元にしたデモンストレーションであり、PDS を外部サービスから個人情報取得のリクエストを受けつけるだけのサービスではなく、外部サービス同士のイベント

ドリブンな個人情報の流通をコントロールするものとして位置づけている。 デモンストレーションでは例として、あるユーザのオンライン・カレンダー内の予定が

確定したという「イベント」を起点に、そのユーザの利用する PDSが別のテレフォニー・サービスを呼び出し、打ち合わせ相手に確認の電話を発信する、というユースケースを紹

介している。ここで PDS は、外部のカレンダーを、ユーザの属性情報とともに仮想的にPDS内部に存在するものとして扱っている。そしてカレンダー上のスケジュールという「個人情報」の変化を検知した PDSは、電話の発信に必要な「呼び出し元となるユーザの情報」を属性情報から取り出し、テレフォニー・サービスの APIを起動するようになっている。

PDS を活用するためには、こうした一連のフローの自動化が必要であるとする同プロジェクトの主張は、今後の PDSの向かうべき方向を示唆するもののひとつとして興味深い。 5. Personal Data Ecosystem Consortium

2010年 10月、Personal Data Ecosystem Consortium[14]が設立された。本コンソーシアムでは「パーソナル・データ・エコシステム」の実現を目指し、PDS を中心に、技術面のみならず、法制度、信頼フレームワーク、相互運用性、マーケティングなども含む、幅

広い観点から議論を行うことを目的としている。 6 まとめ

Personal Data Serviceの概念は以前から存在したが、最近になって再度注目されるようになってきている。その背景には、OpenIDや OAuthに代表されるアイデンティティ技術仕様の普及、Open Identity Trust Framework[15]を中心とする信頼フレームワーク確立の兆し、自己情報コントロールが必要であるという認識の高まりなど、複数の相乗的な要因

がある。 市場には現在、Kynetx 社の他に Statz[16]、Personal[17]、Sing.ly[18]など、PDS のコンセプトを元にした、あるいはそれに類するサービスを提供する企業が次々と登場してい

る。また世界経済フォーラムにおけるイニシアチブのひとつとして Rethinking Personal Data プロジェクトが発足するなど[19]、個人情報の活用について、世界的にも関心が高まりつつある。

2011年はテクノロジーの観点だけではなく、Personal Data Ecosystem Consortiumを中心に、より広範な議論が起こると思われる。

以上

35

参考文献

[1] Main Page - Project VRM http://cyber.law.harvard.edu/projectvrm/Main_Page

[2] Personal Data Service Overview - Eclipsepedia

http://wiki.eclipse.org/Personal_Data_Service_Overview

[3] Higgins Home http://www.eclipse.org/higgins/

[4] Project Danube | Open-Source Sofware for Identity & Personal Data Services

http://projectdanube.org/

[5] OASIS XRI Data Interchange （XDI） TC http://www.oasis-open.org/committees/xdi/

[6] OAuth 2.0 ? OAuth

http://oauth.net/2/ [7] OAuth 2.0 with a Personal Data Store on Vimeo

http://vimeo.com/15504854 [8] OStatus interview with Markus Sabadello | OStatus

http://ostatus.org/2010/10/26/ostatus-interview-markus-sabadello [9] OStatus with a Personal Data Store on Vimeo

http://vimeo.com/15341126 [10] Mydex ≫ Prototype

http://mydex.org/prototype/ [11] What is the MYDEX Prototype? - IIW

http://iiw.idcommons.net/What_is_the_MYDEX_Prototype%3F [12] Kynetx ? This Changes Everything

http://www.kynetx.com/

36

[13] Phil Windley's Technometria | Kynetx and Personal Data Services: Project Neck

Pain http://www.windley.com/archives/2010/10/kynetx_and_personal_data_services_project_neck_pain.shtml

[14] Personal Data Ecosystem Consortium

http://personaldataecosystem.org/ [15] The Open Identity Trust Framework(OITF）Model

http://openidentityexchange.org/sites/default/files/the-open-identity-trust-framework-model-2010-03.pdf

[16] Statz: Take Control and Own Your Data

https://www.statz.com/ [17] Own, share, and manage your personal information | Personal

http://www.personal.com/ [18] Sing.ly

http://sing.ly/ [19] Rethinking personal data | World Economic Forum

http://www.weforum.org/issues/rethinking-personal-data

37

6 DNSSEC 展開の動向

木村 泰司 1. 2010 年下半期の動き

2010 年度後半、ルートゾーンへの TLD の DS レコードの登録が相次いで行われた。また国内において DNSSEC の導入・運用に関するノウハウの共有の促進等を行っているDNSSEC ジャパンでは技術的なレポートが公開された。本稿では 2010 年度下半期のDNSSECの展開の動向ついて述べる。

2. ルートゾーンへのトップレベルドメインの DS レコードの登録

DS（Delegation Signer）リソースレコード（以下、DSレコードと呼ぶ）は、子ゾーンのゾーン署名で使用される鍵（以下、ゾーン鍵と呼ぶ）のひとつのメッセージダイジェス

ト（ハッシュ値）が入るリソースレコードである。親ゾーンに DSレコードが登録されるとDNSSECにおける署名の連鎖ができるため、ドメイン名におけるゾーン署名を検証しやすくなる。ルートゾーンは orgや netといったトップレベルドメイン（Top-Level Domein - TLD）の親ゾーンであるため、ルートゾーンにおける DSレコードの登録は DNSSECの展開という意味でその意義が大きい。

2010年 7月 18日に行われたルートゾーンへの署名に続き、2010年度後半には以下のトップレベルドメインの DSレコードが行われた。

「.ORG」の DSレコード登録（2010年 7月 23日） 「.NET」の DSレコード登録（2010年 12月 7日） 「.ARPA」の DSレコード登録（2010年 12月 8日） 「.JP」の DSレコード登録（2010年 12月 10日）

「.ARPA」の DSレコード登録の後、ゾーン鍵が登録されていた DLV Registry [1]から

DS レコードと同じ役割を持つ DLV レコードが削除され、本来的なゾーン鍵の提供が行われるようになった。

DNSSECの展開に関する情報提供を行っている DNSSEC Deployment Initiative [2]のMLにおける情報では、「.COM」の DSレコード登録は 2011年 3月に行われる見込みである。 3. DNSSEC ジャパンにおける技術情報の公開

DNSSEC ジャパンは、DNSSEC の導入・運用に関する課題の整理と検討を行い、参加者の技術力の向上、ノウハウの共有を促進することを目的とした会合で、ツールの提供や

普及のための技術解説などの活動が行われている[3]。

38

DNSSECジャパンのプロトコル理解 SWG（サブWG）では、DNSSEC関連の RFCの一覧と解説資料が公開された。

DNSSEC関連 RFC

http://dnssec.jp/?page_id=124 RFCの、原文へのリンク、和訳、解説資料が掲載されている。

また、技術検証 WG では技術的な調査や検証活動の成果である資料が公開された。技術検証WGのWebページのURLと掲載されている資料を以下に示す。

技術検証WG 資料

http://dnssec.jp/?page_id=307

掲載されている資料 DNSSECの仕組みと現状 DNSSEC導入に当たって DNSSEC を利用するリゾルバーのためのトラストアンカーの設定方法について

レジストリの鍵登録インターフェースに関する調査報告 レジストラ移転ガイドライン

この他にも DNSSECに関わる情報が公開されている。国内における DNSSEC導入や運用に役立つ情報源であると言える。 4. DPS の公開状況

DPS（DNSSEC Practice Statement）はゾーンの登録要件や設備、システムのセキュリティなどの DNSSEC の運用に関して網羅的に記述する文書で、DNSSEC の運用者が運用の方針や実施内容を網羅的に検討したり運用のレベルを保ったりすることに利用できる。

DPSのフレームワークは IETFで提案されている[4]。 2010年度後半、ルートゾーンに DSレコードが登録されている TLDについて DPSが公開された[5]。

JPドメイン名における DNSSEC運用ステートメント（JP DPS）

https://jprs.jp/doc/dnssec/jp-dps-jpn.html

DNSSEC Practice Statement for the JP Zone (JP DPS)（JP DPSの参考訳）

39

https://jprs.jp/doc/dnssec/jp-dps-eng.html

VeriSign DNSSEC Practice Statement for NET Zone http://verisigninc.com/assets/20100925-NET+DPS-FINAL.pdf

(.SE) DNSSEC Practice Statement (DPS)

http://www.iis.se/dl/DPS-PA9-ENG.pdf DNSSECの導入や運用にあたって、組織的また技術的に検討すべき項目やどのような運用を行えばよいかという検討のために参考になると考えられる。

5. 国内における DNSSEC の今後

2011年 1月 16日、「.JP」において DNSSEC が導入された[6]。今後、ISP事業者等における DNSSEC対応によって、「.JP」の多くのユーザが DNSSECを導入したドメイン名を利用できるようになる。 一方、いくつかの TLDでは DNSSECの不具合が報告されており、運用のノウハウが蓄積されるべき時期であると考えられる。DNSSEC の導入や運用にあたっては DPS の記述項目にあるような事前対策、事後対策を含めて検討されることが望ましいと考えられる。

以上

40

参照文献 [1] ISC's DLV Registry

https://www.isc.org/solutions/dlv [2] DNSSEC Deployment Initiative

http://dnssec-deployment.org/ [3] DNSSECジャパン，「設立趣意書」

http://dnssec.jp/?page_id=2 [4] “DNSSEC Policy & Practice Statement Framework”, November 9, 2010

http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework-03

[5] ルートゾーンのDPSについては本タスクグループの 2010年度上期の報告書を参照のこと。

http://www.ipa.go.jp/security/fy20/reports/tech1-tg/2_09.html [6] 日本レジストリサービス，「JPドメイン名サービスへの DNSSECの導入予定につい

て」 http://jprs.jp/info/notice/20090709-dnssec.html

41

7 RPKI を用いたルーティング・セキュリティの動向

木村 泰司 1. RPKI とリソース証明書の展開

リソース PKI（以下、RPKI と呼ぶ）は、IP アドレスなどのアドレス資源の利用権利を示す電子証明書（以下、リソース証明書と呼ぶ）を発行する仕組みである。リソース証明

書には IPアドレスや AS番号が記載されており、正しく割り振られたアドレスであることを示している。リソース証明書はインターネットにおける経路広告を始めるときに、その

IP アドレスが登録と異なる不正なものではないことを示したり、ISP（インターネットサービスプロバイダー）などにおけるルータで受信されたインターネットの経路情報が本来

の正しいものであることを確認したりするために使うことができる。詳しくは本タスクグ

ループの以前の報告を参照されたい[1]。 2010年度後半、インターネット経路制御の仕組みにおける公開鍵暗号技術を用いたセキュリティの仕組みである RPKIが展開してきた。本稿ではその展開状況について述べる。

2. すべての RIR におけるリソース証明書の提供

インターネットのアドレス資源を管理している RIR [1]では、リソース証明書の提供に取り組んできており、2011年 1月、すべての 5つの RIRで提供が開始した。2011年 2月 3日に IANA の IPv4 アドレスプールから最後の 5 つの/8 が割り振られ、IPv4 アドレスのIANAプールが枯渇したが、この IANAプールの枯渇より前にすべての RIRでリソース証明書の提供が開始したことになる。各 RIRの RPKIに関するWebページの URLを以下に示す。

Resource Certification (APNIC) http://www.apnic.net/services/services-apnic-provides/resource-certification

RIPE NCC Resource Certification (RIPE NCC) http://www.ripe.net/certification/

ARIN Resource Certification (ARIN) https://www.arin.net/resources/rpki.html

Resource Certification at LACNIC (LACNIC) http://lacnic.net/en/rpki/

AfriNIC's Resource Certification (AfriNIC) http://www.afrinic.net/membership/certification.htm

42

3. IETF におけるルータとの連携に関わる標準化と実装の状況

IETFの SIDR WG（Secure Inter-Domain Routing WG）[2]では、BGPルータで RPKIを利用するためのプロトコルである RPKI/Routerプロトコルが提案されており[3]、一部では実装が開始された。このプロトコルは、trusted cacheと呼ばれるリソース証明書や ROA（Route Origin Authorization）の検証結果を持つサーバと BGPルータの間のプロトコルで、BGP ルータで RPKI 関連の処理を行わないことで BGP ルータの処理内容をシンプルに保つことができる。いよいよ RPKI がインターネットにおけるセキュアな経路制御に利用できる技術が実装され始めたことになる。 また北京で行われた第 79回 IETF [4]の期間中、RPKIの実装を持ち寄って相互運用性を確認する会合が開かれた。特に決まった時間は設けられず、IETFの期間中、好きな時間にターミナルルームに集まって実装を持ち寄る形で検証作業が行われた。この会合は ISC のRPKI testbed ML参加者が中心となっているが、ISCの実装の他にも BBN Technologies社や APNIC、RIPE NCC [1]の実装なども検証が行われていた。RPKI testbedでわかっている RPKI のリポジトリ（発行されたリソース証明書等を公開するサーバ）の一覧と、発行数などが以下のWebページにまとめられている。

rcynic summary

http://www.hactrn.net/opaque/rcynic.html ※rcynicはリソース証明書などをリポジトリから収集し検証するプログラム。本Webページでは定期的に rcynicが実行され、結果が表にまとめられている。

今後、ISP 事業者などにおいても RPKI の実装を利用し、技術検証が行われる活動が国際的に行われていくことが考えられる。

以上

43

参考文献

[1] 国際的に 5つに分けられた地域の IPアドレスやAS番号の登録管理を行っている組織

で、APNIC（アジア太平洋地域）、ARIN（北米及び中米地域）、RIPE NCC（ヨーロッパ地域）、LACNIC（ラテンアメリカ地域）、AfriNIC（アフリカ地域）がある。日本の IPアドレスや AS番号の登録管理を行っている JPNICは、APNICからアドレスの割り振りを受けている。

[2] Secure Inter-Domain Routing (sidr)

http://datatracker.ietf.org/wg/sidr/charter/ [3] The RPKI/Router Protocol,

http://tools.ietf.org/id/draft-ymbk-rpki-rtr-protocol-06.txt [4] IETF 79 - Beijing, China

http://www.ietf.org/meeting/79/index.html

44

8 OpenFlow によるネットワーク分離

馬場 達也 1. はじめに

近年、ソフトウェアやハードウェアなどのリソースをネットワーク経由で利用する形態

である「クラウドコンピューティング」が流行っている。クラウドコンピューティングに

は、SaaS（Software as a Service）や PaaS（Platform as a Service）、IaaS（Infrastructure as a Service）などの「パブリッククラウド」や、企業毎に自社のデータセンタ上でサーバ仮想化技術を使用して、社内の部門に対して仮想サーバの貸し出しサービスを行う「プラ

イベートクラウド」などが存在するが、複数の企業のプライベートクラウドを物理的に同

じインフラ上で実現することでコスト削減を実現する「仮想プライベートクラウド」が注

目されてきている。仮想プライベートクライドでは、サーバの論理分割だけでなく、ネッ

トワークの論理分割を行い、各社のプライベートクラウド間のセキュリティを確保する必

要がある。本稿では、この論理分割を実現するための新しいネットワーク技術である

OpenFlowの概要について説明する。 2. 「仮想プライベートクラウド」実現の課題

現在は、各社が自社のデータセンタに独自にプライベートクラウドを構築している。こ

の状態では、サーバの集約効果はあるものの、コスト削減効果は限定的であった。このた

め、サーバだけでなく、データセンタやネットワークも他社と共有することでコストを削

減する「仮想プライベートクラウド」が注目されている（図 1）。

図 1： 仮想プライベートクラウドの仕組みとメリット

45

1台の物理サーバを複数の企業が共同利用するためには、サーバ仮想化技術を利用するが、ネットワークを複数の企業が共同利用するためには、VLAN（Virtual Local Area Network）などのネットワーク仮想化技術が必要となる。 この仮想プライベートクラウド環境においては、いくつかの問題が指摘されている。ひ

とつは、VLANなどの設定が複雑になることである。ネットワーク機器を論理的に分割するためには、レイヤ 2スイッチであれば VLAN、レイヤ 3スイッチであれば VRF（Virtual Routing and Forwarding）、ファイアウォールやロードバランサであれば仮想ファイアウォールや仮想ロードバランサ（名称はベンダによって異なる可能性がある）などの技術が存

在するが、仮想プライベートクラウドを利用する企業が増える度に、それぞれのネットワ

ーク機器にこれらの仮想化のための設定を行う必要がある。仮想化の設定は複雑になるた

め、設計・設定ミスが増加することが予想されるだけでなく、他社が利用中のネットワー

クの設定を変更する際の設定ミスの影響が、各社毎にネットワークを構築している場合と

比較して大きいという問題がある。また、物理ネットワーク構成と論理ネットワーク構成

が大きく異なるため、各社のネットワークがどのようになっているか把握することが難し

いという問題がある。 2つ目は、VMwareの VMotionや、Xenの XenMotionのような、仮想化環境特有の「ライブマイグレーション」への対応である（図 2）。これは、仮想サーバが、サービスを停止することなく物理サーバを超えて移動することができるというものであり、プライベート

クラウドのように、ネットワーク全体が同じ VLANに所属していれば問題ないが、仮想プライベートクラウドでは、各社毎に異なる VLANを使用するため、移動先の物理サーバ内の仮想スイッチや、その物理サーバまでのスイッチの VLANの設定をライブマイグレーションにあわせて変更する必要がある。この VLANの設定変更は、仮想スイッチのみであれば VLANの設定を自動的に修正するような製品も存在するが、ネットワーク全体の VLANの設定を自動的に変更できる製品は本稿執筆時点ではほとんど存在しない。このため、ラ

イブマイグレーション時には、ネットワークの設定は手動で行わなければならない場合が

多く、仮想化のメリットを最大限に享受することができないという問題がある。

46

図 2： ライブマイグレーション時のネットワーク設定の変更

OpenFlowの概要 OpenFlowとは、2008年より、スタンフォード大学を中心とした「OpenFlowスイッチングコンソーシアム」が提唱している次世代ネットワーク制御技術である

（http://www.openflowswitch.org/）。OpenFlowでは、スイッチのパケットを転送する「データプレーン」と、ルーティングの計算などを行う「コントロールプレーン」を分離して

おり、12情報（入力スイッチポート、VLANID、送信元/宛先MACアドレス、送信元/宛先IPアドレス、プロトコル、送信元/宛先ポートなど）による「フロー」をベースに経路制御を行う。OpenFlowプロトコル 1.0が 2009年 12月 31日にリリースされており、現在、OpenFlowプロトコル 1.1の仕様を策定中である。

OpenFlowを活用することにより、データの流れを柔軟に制御することができるようになるだけでなく、標準化されたプロトコルにより、マルチベンダ環境でも一元制御が可能と

なる。 3. OpenFlow のアーキテクチャ

OpenFlowは、図 3のように、「OpenFlowスイッチ」、「OpenFlowコントローラ」、「OpenFlowプロトコル」の 3つから構成される。

OpenFlowスイッチ フローテーブルを見てパケットを転送する機能と、OpenFlowのメッセージを交換する機能のみを持ったスイッチ。物理スイッチと仮想スイッチがある。

OpenFlowコントローラ

47

OpenFlowスイッチで構成されるネットワーク全体のルーティングの計算を行い、各 OpenFlowスイッチのフローテーブルを作成する。

OpenFlowプロトコル OpenFlowコントローラと OpenFlowスイッチの間のメッセージを交換するためのプロトコル。主に、OpenFlowコントローラで生成されたフローテーブルをOpenFlowスイッチに伝えたり、OpenFlowスイッチの情報を OpenFlowコントローラに伝えるために利用される。プロトコルは OpenFlowスイッチングコンソーシアムによって標準化されているため、マルチベンダ対応が可能である。

図 3： OpenFlowのアーキテクチャ

4. フローテーブルの構造

フローテーブルは、以下のレイヤ 1からレイヤ 4までの 12の情報により識別される「フロー」と、そのフローに対する「アクション」で構成される。アクションは、Forward、Enqueue、Drop、Modifyの 4種類が定義されている。

レイヤ 1情報 - 送信スイッチポート番号

レイヤ 2情報

- 送信元MACアドレス - 宛先MACアドレス

48

- イーサタイプ - VLANID - VLANプライオリティ

レイヤ 3情報

- 送信元 IPアドレス - 宛先 IPアドレス - プロトコル番号 - ToS（Type of Service）

レイヤ 4情報

- 送信元ポート番号 - 宛先ポート番号

5. OpenFlow による論理ネットワークの分割

ネットワークの論理分割の方法として VLANをはじめとする従来技術を使用する場合は、宛先 IPアドレスをもとにルーティングを行うため、図 4のように、レイヤ 3スイッチ、ファイアウォール、ロードバランサ、レイヤ 2スイッチ、サーバなどを垂直に並べる方法が取られた。しかし、企業によっては、ファイアウォールを必要としない場合や、ロードバ

ランサを使用しない場合などが考えられる。OpenFowを使用すると、図 5のように、同じ物理構成でありながら、異なる論理構成のネットワークを構築することができるようにな

る。

図 4： 従来技術による論理分割のイメージ

49

図 5： OpenFlowによる論理分割のイメージ

6. 既存技術（VLAN）と OpenFlow との比較

仮想プライベートクラウドを実現する方式として、既存技術である VLANと OpenFlowを活用する場合の比較を表 1に示す。OpenFlowでは、レイヤ 2までの情報として、VLANID以外に入力スイッチポートや送信元/宛先MACアドレスを利用できるというメリットがある。このため、VLANIDに依存しない論理分割が可能である。特に、仮想サーバのMACアドレスを宛先とするフローを定義しておくことで、ライブマイグレーションに自動的に

追随することができる。

表 1： 既存技術（VLAN）と OpenFlowとの比較

50

7. OpenFlow の対応状況

現在、オープンソース・ソフトウェアの仮想スイッチ「Open vSwitch」、同じくオープンソース・ソフトウェアの OpenFlowコントローラ「NOX」、Citrixからリリースされている「XenServer 5.6 Feature Pack 1」の仮想スイッチが OpenFlowプロトコル 1.0に対応している。また、NEC、Cisco Systems、Juniper Networks、Hewlett-Packard（HP）、Arista Networksなどのネットワーク機器ベンダが OpenFlowスイッチのプロトタイプを開発している。 8. まとめと今後の展開

現在、OpenFlowスイッチングコンソーシアムにて、OpenFlow 1.0の仕様が公開中であり、OpenFlow 1.1の仕様について議論しているところである。そして、NEC、HP、Juniperなどのネットワーク機器各社が OpenFlowスイッチのプロトタイプの開発をしているところであり、仮想スイッチの Open vSwitchや Citrixの XenServerは、標準で OpenFlowに対応している。

OpenFlowは、ネットワークの論理分割が容易かつ柔軟にできるという点や、フローを細かく定義することで、レイヤ 4レベルのファイアウォールと同等の機能をインフラ自体で提供することが可能というセキュリティ上のメリットがあり、仮想プライベートクラウド

において、標準の技術となる可能性がある。 以上

51

9 トンネリング技術のセキュリティ上の弊害と IPv6 移行技術における経路ル

ープの危険性 太田 耕平、キニ グレン マンスフィールド

1. はじめに

インターネットの拡大に伴って必要にせまられて登場した NAT （Network Address Translation）技術は、技術的には不十分であるにもかかわらずセキュリティ装置としても期待され、当初の想定を越えて広くいきわたっている。その結果本来 NAT 技術を不要にすることを期待されて登場した IPv6ネットワークにおいても、その必要性が議論されている[1][2]。 限られた数のグローバルアドレスを共有するNAT技術は、インターネットに実用的な拡張性をもたらした。しかし、その代償として、見かけ上ネットワークを分割することがフィルタ機能を提供して

いるように見え、セキュリティに対する誤解と過信の温床となるとともに、一方では次世代の IPv6においても本来の理念である End-to-End の接続性を阻害するものとして大きな懸念事項となっている[3]。

NAT 技術によって分断された End-to-End の接続性は、理念だけではなく実際の利便性にも悪影響をもたらしており、如何にNATを越えて通信できるようにするかが課題になっている。このような背景の下、数多くのトンネリング技術が開発されている。Teredo [4]、L2TPv2 [5]、L2TPv3 [6]などのトンネリングプロトコルのほか、最近増加している SSL（Secure Socket Layer）ベースのVPN（Virtual Private Network）ソリューションもトンネリング技術を利用している。多くのトンネリング技術は、既存のコネクション管理を避けるために UDP のようなコネクションレスのプロトコル上に実装されるか、最も広い範囲で通信が確保されている HTTP を利用することで接続性を高めている。 しかし、トンネリング技術は経路上のなんらかの障壁を越えて通信を確立する技術であるため、

現在一般的に用いられているネットワークベースの侵入検知システムやファイアウォール等のセキ

ュリティシステムと極めて相性が悪い。また、トンネリング技術のいくつかは NAT によって分断された End-to-End の接続性を新たに確保するために、不完全ながらも一定の役割を果たしているNAT のフィルタ機能をさらに低下させており、NAT のフィルタ機能への過信をより深刻な問題としている。 トンネリングによるセキュリティへの脅威については、認知が進んでおらず、十分な対策がとられ

ているとはいえない。特に明示的な設定を必要としない自動トンネリング技術は、ネットワーク管理

者が気づかないうちに新たなネットワーク接続点を作り出し、潜在的なセキュリティ上の脆弱点とな

りえる。 そのような中、IPv4 アドレスの枯渇[7]に伴い IPv6への移行が急務となっている。この変更はこれまでのインターネットを置き換える大規模なものであるため、段階的な措置が不可欠であり、

IPv4 ネットワークの中に段階的に IPv6 ネットワークを構築し、相互に接続できるトンネリング技術

52

は重要な役割を果たすことが期待されている。 本稿では、NAT を跨いで機能するトンネリング技術がもたらすセキュリティ上の脅威についての

IETF の動向と、IPv6 への移行技術としてのトンネリングで、具体的に危険性が指摘されている経路ループについて述べる。 2. トンネリング技術の利用に伴うセキュリティ上の問題点

まもなく RFC として発行される見込みの[8]では、トンネリング技術と既存のセキュリティ対策との親和性の問題、トンネリング技術が NAT にもたらす影響、および、トンネリング技術の悪用の観点からトンネリング技術のセキュリティ問題を論じている。[8]は、Teredo プロトコルのセキュリティ上の懸念をとりまとめた I-D（Internet-Draft）[9]として起草されたが、その後、一般的なトンネリングプロトコルに対するものとして改められた。 3. トンネリング技術と既存のセキュリティ対策との親和性

トンネリング技術は、ネットワーク上のなんらかの障壁を越えて通信を確保する技術であるため、

現在一般的に使われている境界型のセキュリティシステムとは本質的な矛盾がある。特にパケット

を監視、解析するネットワークベースの侵入検知システムやファイアウォールとの相性は悪く、これ

らに依存した管理には大きな危険性がある。 3.1 トンネルパケットの検査とフィルタリングの困難

ネットワークベースのセキュリティシステムは、ネットワークを通過するパケットを監視・解析するこ

とで通信を分類し、ポリシにしたがって不正な通信を検知、フィルタする。しかし、トンネル通信のパ

ケットは一般の UDPパケットや HTTPパケットなど、既存のパケットのペイロードとしてカプセル化されているため、従来のアドレスやポートといったインターネットで広く公開、標準化されているパラ

メータでフィルタすることができない。 この問題は、システムの負荷とも密接な関係がある。現在標準化されているパケット構造にはトン

ネルパケットを特定する一般的な仕組みがなく、IPv6移行のための 6to4 [10]が IPヘッダ内のプロトコルフィールドで 41 を指定するなど、ごく限られた対応となっている。そのため各トンネル通信を解析する前に、トンネル通信そのものを特定することも困難である。しかし、全てのパケットに対し

てペイロードを検査し、トンネル通信があるかどうかを確認するのは明らかに非現実的である。 また、このことは、トンネリングプロトコル毎に個別の解析ロジックを追加する必要があることも意

味している。トンネリングプロトコルの設計に一般的な仕組みがないため、IETF 等で標準化されたプロトコル以外にも多くの詳細が公開されていないプロトコルも存在している。したがって、対象のト

ンネリングプロトコルに対応するロジックが実装されるまで、対象の通信の解析ができないというシ

グネチャ型のウイルス対策と同様の問題をもたらす。現在これらのセキュリティシステムを頻繁に更

新するような運用は一般的ではなく、このセキュリティ上の空白は長期にわたることもあり得る。さら

にはトンネリングプロトコルがパケットペイロードを利用するため、ペイロードが暗号化された場合に

53

はネットワークベースのセキュリティシステムにできることは、ほとんどない。 3.2 トンネリング通信の監視・管理の課題

ネットワークベースのセキュリティシステムは集中管理が容易であるため、広く利用されているが、

トンネル通信に対しては前節で述べた理由により本質的に適用が難しい。また、トンネリング技術

は、ネットワークへの出入り口を新たに設置することと同義となるため、原則としてトンネルの終端地

点には、セキュリティ対策が必要となる。 例えば、今日、ネットワークの境界では入ってくるパケットの宛先アドレス、出て行くパケットの発

信元アドレスを確認して無関係なパケットの出入りをフィルタする（Ingress/Egress フィルタ）ことが、基本的なセキュリティ対策の一環として一般化している[11]。しかし、トンネルの内部で利用されているアドレスはその外部からは隠蔽されており、これに対してフィルタを適用できるのはトンネルの

終端があるサーバ上となる。Teredo を規定している[4]でもローカルファイアウォールの利用を推奨している。 つまり、前節で指摘した様々なトンネリングプロトコルへの対応、暗号化に対する問題など、トン

ネリング技術に対するセキュリティ対策には、トンネルの終端地点の管理とそこへのセキュリティ対

策が重要となる。組織内でトンネリング技術を利用する際にはネットワーク境界をまたぐようなトンネ

ルではなく、セキュリティ境界でトンネルを終端させるような手法が望ましい。 例えば、IPv6 への移行技術としてトンネリングを利用する場合は、ネットワーク内ではトンネルを利用せずネイティブの IPv6 を利用することでトンネルがセキュリティ境界を跨がないようにするか、もしくはトンネルを利用する場合でも（IPv6アクセスのある）組織内のルータで終端させ既存のセキュリティ境界と整合させることが望ましい。 一方でトンネルの終端地点の管理は大きな課題である。トンネリング技術は容易に利用でき、構

築に特別な機器や技術を必要としない。そのためネットワーク管理者がその存在をすべて知ること

が困難であり、さらにそれらすべてに適切なポリシを適用することは困難である。 4. トンネリング技術が NAT にもたらす影響

トンネリング技術の多くは、コネクションを持たないUDPを基盤にするなど、NATを通過することを前提とし、いくつかはさらに積極的な機能も備えている。このことは元々十分ではない NAT のフィルリング機能をより脆弱にする結果となっている。 4.1 NAT を越えるトンネリングによる曝露領域の拡大

トンネリング技術が開けるNATの穴によって、攻撃にさらされる部分が広がる。特にインターネットからのアクセスを受け入れるトンネリングは、恒常的にNATに開けられた穴から攻撃をうける可能性がある。このとき、通常の TCP/IP スタックとインタフェース以外にトンネルインタフェースおよびトンネルの内部ネットワークの実装の脆弱性も攻撃対象となりえる。例えば IPv4による IPv6のトンネリングでは、両バージョンの IPプロトコルスタックの脆弱性が攻撃の対象となりえる。

54

4.2 NAT フィルタ効果の脆弱化

NATによるフィルタリング効果は見かけ上のものであるため、NATが外部と内部をつなぐために管理している対応関係の情報があれば、外部から内部に対してもパケットを送信することが可能と

なる。 そしてトンネリングによる NAT の穴は、他の一般的な通信があける穴よりも知られ易い。トンネル通信は通信の維持時間が長く、その分使われているポート情報が発見される危険性が高くなる。ま

た、Teredoなどいくつかのプロトコルでは、クライアントの IPv6アドレスが NATの外側の IPv4アドレスとポート番号を含んでいる。そのため IPヘッダによって NATの利用状況が漏洩する危険性がある。 さらに Teredoでは NAT を超える通信を確立するために、Bubbleパケットと呼ばれる手法を利用してある種の成りすましを実行することで、NATを越えて任意の相手との通信を可能としている。これは IP アドレスによる接続制限を無効にし、外部からのアクセスを可能とできることを意味している。 5, トンネリング技術の悪用

6to4 や Teredo などのトンネリングプロトコルにおいては、使用するアドレスが定義されているため、そのアドレスの利用から、トンネルの存在と、そのプロトコル種別を類推することが可能となる。

また、トンネリング技術は特定のプラットフォームだけで利用できるものもあり、例えば Teredo を利用していることが特定されれば、そのプラットフォームがWindows であることなどが実際にアクセスすることなく特定できる。 一方で、利用者にとっては、トンネルサーバを全面的に信用することは様々なフィッシングのリス

クにさらされることを意味している。トンネル通信を利用しているかどうかはアプリケーションレベル

ではわからないため、DNS Spoofなどの方法で、クライアントのサーバ設定アドレスを変更できたとすれば、man-in-the-middle（中間者による）攻撃が成立しえる。 6. IPv6 配備におけるトンネリング技術の問題点

本章では、普及が急がれる IPv6への移行に利用されるトンネリング技術の危険性、具体的にはDoS（サービス妨害）攻撃に利用される危険性がある経路ループの問題を分析した I-D [12]を概説する。本問題は、Protocol 番号 41 として定義されているカプセル化を利用するすべての自動トンネル技術が影響を受け、ISATAP [13]、6to4 [14]および 6rd [15]を含んでいる。なお、前章までに多くの例示がある Teredoについては別の I-D [16]で論じられている。 本攻撃は次の条件で可能になる。ふたつのルータ R1 と R2はそれぞれ protocol-41 カプセル化を利用するトンネルインタフェースを有している。それぞれのインタフェースには IPv4 アドレスとして IP1、IP2が割り当てられている。そして、それぞれのルータは IPv6のネイティブインタフェースを持ち、IPv6 パケットを適切にフォワードする。それぞれのルータのトンネルに割り当てられた

55

IPv4 アドレスは、同じアドレスグループ（どちらもパブリック、どちらも同じ内部ネットワークのプライベートなど）に属している。言い換えればふたつのトンネルを持つ IPv4 ネットワークでこの攻撃が成立する。 本攻撃は、IPv6パケットの発信元と宛先アドレスを偽装することで、IPv6ネットワーク上では R1からR2へルーティングされるパケットが、それをカプセル化した IPv4のトンネル上では逆にR2からR1へルーティングされるようにすることで成立する。自動トンネルではトンネル用の IPv4アドレスが IPv6アドレス内に埋め込まれているため、これが可能となっている。 本攻撃のメカニズムは下記の通り。

(1) 攻撃者は自動トンネルパケットを生成しR2が接続されている IPv6ネットワークに送信する。

このパケットは IPv6の宛先を R2のトンネルインタフェースの先に相当する架空のアドレスとし、自動トンネルのための IPv4 の宛先アドレスを R1 のトンネルインタフェースアドレス（IP1）とする。このとき、IPv6発信元アドレスは R1のトンネルインタフェースの先に相当する架空のアドレスとし、自動トンネルのための IPv4の発信元アドレスをR2のトンネルインタフェースアドレス（IP2）とする。ここで意図的に偽装されているのは IPv6 の宛先アドレスと発信元アドレスである。

(2) このパケットは宛先がR2のトンネルの先であると偽装された IPv6パケットなので、IPv6ネットワーク上で R2に経路制御される。受け取った R2はそれをトンネルインタフェースに転送し、対応する IPv4 アドレスである IP1 を宛先とする IPv4パケットでカプセル化する。このときカプセル化している IPv4パケットの発信元は IP2 となる。

(3) カプセル化している IPv4パケットは IPv4ネットワーク上で経路制御され、R1の IPv4インタフェースに到着する。そしてトンネル経由のパケットとして処理される。

(4) IPv4 パケットの発信元アドレスが IPv6 の発信元アドレスに関連付けられているため、R1はそれを非カプセル化する。取り出された IPv6パケットの宛先は R1のトンネルインタフェースの先には存在しないため、R1はそれを IPv6のネイティブインタフェースに転送する。このパケットはステップ 1で攻撃者が送信したパケットなので、R2に転送される。

上記のステップによってステップ 1 で生成されたパケットは R1-R2 間をループし、それは IPv6パケットヘッダのHop Limitが 0になるまで継続する。この攻撃は、R2は R1が IP2に関連していることがわからず、逆に R1は R2が IP1に関連していることがわからないことを利用している。なお、この攻撃は R1 と R2が IPv6のネイティブインタフェースを持たず、別のトンネル経由で IPv6ネットワークに接続している場合にも成立する。これらの問題に対応するためには Ingress/Egressの運用、全トンネルインタフェースの存在の把握と管理など、セキュリティ境界としての適切な運用

が必要である。

56

IPv6 NetworkIPv4 Network

R1

R2

Packet to network2

Encapsulation

DecapsulationProtocol-41 Encapsulation

IPv4:IP2

IPv4:IP1

図：IPv6配備におけるトンネリング技術の問題点 7. まとめ

本稿では、トンネリング技術のセキュリティ上の課題についての最新動向について概観するとと

もに、具体的な問題点の一つとして、IPv6 への移行時に起こりえるトンネリング技術を利用したDoS攻撃の危険性を解説した。本格的な IPv6への移行期を迎え、トンネリング技術は強力なツールであるが、その運用には NAT への過信も含めたセキュリティ体制の見直しが不可欠であるといえる。

以上

57

参考文献

[1] 太田 耕平, Glenn Mansfield, KEENI, 「IPv6ネットワークにおけるローカルネットワークの保護」，IPA 情報セキュリティ技術動向調査（2010 年上期），2010年 9月.

http://www.ipa.go.jp/security/fy22/reports/tech1-tg/a_06.html [2] G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein, “Local Network

Protection“, RFC 4864, May 2007. http://tools.ietf.org/html/rfc4864

[3] D. Thaler, G. Lebovitz, “IAB Thoughts on IPv6 Network Address Translation”, RFC

5902, July 2010. http://tools.ietf.org/html/rfc5902

[4] Huitema, C., "Teredo: Tunneling IPv6 over UDP through, Network Address

Translations (NATs)", RFC 4380, February 2006. http://tools.ietf.org/html/rfc4380

[5] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two

Tunneling Protocol "L2TP"", RFC 2661, August 1999. http://tools.ietf.org/html/rfc2661

[6] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling, Protocol - Version 3

(L2TPv3)", RFC 3931, March 2005. http://tools.ietf.org/html/rfc3931

[7] 社団法人日本ネットワークインフォメーションセンター，「IPv4アドレスの在庫枯渇に

関して」，2011年 2月 3日． http://www.nic.ad.jp/ja/ip/ipv4pool/

[8] S. Krishnan, D. Thaler, J. Hoagland, “Security Concerns With IP Tunneling”,

Internet-Draft, October 25, 2010. http://tools.ietf.org/html/draft-ietf-v6ops-tunnel-security-concerns-04

58

[9] J. Hoagland, S. Krishnan, “Teredo Security Concerns”, Internet-Draft, February 25,

2008. http://tools.ietf.org/html/draft-ietf-v6ops-teredo-security-concerns-02

[10] B. Carpenter, K. Moore, “Connection of IPv6 Domains via IPv4 Clouds”, RFC 3056,

February 2001. http://tools.ietf.org/html/rfc3056

[11] P. Ferguson, D. Senie, “Network Ingress Filtering: Defeating Denial of Service

Attacks which employ IP Source Address Spoofing”, RFC 2267, BCP 38, May 2000. http://tools.ietf.org/html/rfc2267 日本語訳：「ネットワーク境界におけるフィルタリング：IP ソース アドレスを偽ったサービス妨害攻撃をくじく」，RFC 2267．

http://www.ipa.go.jp/security/rfc/RFC2267JA.html [12] G. Nakibly, F. Templin, “Routing Loop Attack using IPv6 Automatic Tunnels:

Problem Statement and Proposed Mitigations”, Internet-Draft, February 04, 2011. http://tools.ietf.org/html/draft-ietf-v6ops-tunnel-loops-03

[13] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing

Protocol (ISATAP)", RFC 5214, March 2008. http://tools.ietf.org/html/rfc5214

[14] Carpenter, B. and K. Moore, "Connection of IPv6 Domains, via IPv4 Clouds", RFC

3056, February 2001. http://tools.ietf.org/html/rfc3056

[15] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

-- Protocol Specification", RFC 5969, August 2010. http://tools.ietf.org/html/rfc5969

[16] F. Gont, “Mitigating Teredo Rooting Loop Attacks”, Internet-Draft, September 8,

2010. http://tools.ietf.org/html/draft-gont-6man-teredo-loops-00