6 月 10 日 午後の部 - 3

なひ「セキュアアプリケーションプログラミング」

スピーカー

なひ氏 ((株) サリオンシステムズリサーチ); SOAP4R, WSDL4R, csv など Ruby の標準添付ライブラリの開発者です。

時間

16:15〜16:47

セッション概要

セキュリティ基礎技術を振舞中心に解説

講演資料

発表資料、ソースコード

• ソースコード全開度 ★★★
• ライブラリ活用度 ★★★
• セキュリティ定石度 ★★★
• gotoyuzo さんよいしょ度 ★★★
• 時間不足度 ★★

ソースコード の動作確認には、rake と OpenPGP ツールキットが必要とのことです。

基礎技術

1. 暗号化 - 第三者に読まれないようにする
2. 認証 - 誰が書いたのかを明らかにする
3. 完全性の保証 - 改竄されていないことを保証する

後者二つは通常ペアとして扱われます。分離すべき用途がないので、これらを別個に扱う技術開発が進んでいないためです (分離して「誰が書いたのか分からないけれども改竄されていないことを保証する」必要がある用途は匿名誘拐犯の身代金要求くらい？)。

認証用の鍵、対称性とアクセス性

認証には送信側と受信側で鍵が対称なもの、対象でないものがあります。

• 対称鍵。何か確実な方法であらかじめ秘密鍵を共有しておく (実は安全に共有するのは非常に難しい問題なのだが)。AES¹ などのアルゴリズムがある。
• 非対称鍵。公開してしまっても問題ない公開鍵と、受信側だけが持っている私有鍵のペアを利用する。RSA² など。

三種類の公開度

• 共通鍵 (以下、seckey)。対称鍵方式³で用いる。通信を行う当事者以外に洩れてはいけない。これを秘密鍵と呼ぶ流儀もあるが、ここでは共通鍵と呼ぶ。
• 私有鍵 (以下、privkey)。非対称鍵方式で用いる⁴。privkey は、その人だけが持っていることがパワーのすべて。
• 公開鍵 (以下、pubkey)。非対称鍵方式で用いる。privkey に対して、1 つの対応する pubkey を使用するが、pubkey から privkey を割り出すことはほぼ不可能。pubkey が通信当事者以外に洩れても安全性に問題ない。pubkey を一般に公開してしまうこともある。

完全性の保証

暗号はあくまでも暗号であり、それそのものでは完全性の保証はしない。ここで、EBC で暗号化したテキストを改竄して見せた。

EBC がいけない。OpenSSL⁵ では、何も考えずに CBC と書いておくべきです⁶。

鍵＋完全性保証のデモ

パスワードで AES を簡単化できます。 素朴な RSA では、鍵のサイズより短いバイト列しか暗号化できないので、用途が非常に限定されます。例えば (と実演すると)、open-uri.rb のソースそのものでは長すぎて無理でした。

そこで、AES 用パスワードを動的に生成し、私有鍵を暗号化する。

• Marshal.dump
• 認証 + 完全化

秘密を共有できている人なら同じ署名が生成できる。 OpenSSL::Digest::なんか.new ――「なんか」はどの手段で署名するのかを指定する。 検証には DSA というものもある。ただし署名用のみ。

例題: アプリケーション間通信

ソースコード を参照のこと。 動作は

• host は外部から Ruby プログラムとりこんで評価実行
• proxy は接続して結果を返す

ものとする。

2_application/21_clientauth

まず何とか安全に送る クライアント認証

署名を送って ソースを送って 評価結果を返して 最初の一行をとって 署名を verify して。

2_application/22_hostcheck

送り先が二つ以上あるとき、送り先を特定するには

2_application/23_mastercontrol

クライアント二つ以上あるとき、集中管理したい。

それにはサーバ側にも鍵を用意する。サーバが一番えらくて「諸君らの鍵はたしかに我輩が認証した」を管理の手引きにする。

2_application/24_nglist

いったん許可したんだけど、もう使わない人は NG にしたい。

サーバ側に NG リストを作って、参照して載ってたら NG とする。

以下、SSL はこんなことまで考えてるから安全、というストーリーでいく。

2_application/25_noreplay

リプレイ攻撃

同じことを何回も繰り返されると、昔取れた許可が不要に長く生き延びてしまう可能性がある。対策としてワンタイム制を導入する。

2_application/26_encrypt

暗号化

2_application/27_ssl

SSL の例

徹底的に考えて設計されたのが SSL なので、みなさんこれを使いましょう。

証明書を作って、それを使って通信する。

最後の例。結構手間なのですが。

• まず CA
• パスワード生成
• 失効リストをつくる
• クライアント鍵をつくる
• サーバ鍵をつくる
• クライアント証明書 パスワード
• サーバ証明書 パスワード

WEBrick 最初の設定の手間だけは若干かかるが、あとは WEBrick が面倒見てくれる。

3_pgp/32_sign

OpenPGP

これは作りかけ。まだまだ生々しい……

まとめ

いまあるツールキットは、まだまだガリガリ。しかも落とし穴いっぱい。

抽象化するひとつの手は OpenSSL マッピングモジュール。現状でも充分すばらしい。 しかもサポートが厚い！ (gotoyuzo 氏)

他の環境では真似できません！ まねの出来ないセキュア・アプリを作ってください！

後藤謙太郎「仕事で使うRuby」

スピーカー

後藤謙太郎氏 (シングラム); benchmark.rb など、Ruby の標準添付ライブラリの開発者で、前セッションで名前の挙がった gotoyuzo 氏とご兄弟です。

時間

16:49〜17:20

セッション概要

Ruby アプリケーションの活用事例を紹介

講演資料

http://www.webrick.org/misc/20060610-rubykaigi2006-gotoken.pdf

• Ruby 関係なくても有用度 ★★
• 業務管理のチケットドリブン度 ★★
• ルックス重要度 ★★★
• ご本人のルックス度 ★★★

わたしと Ruby

PC を借りてプレゼンを入れといたら、いつの間にか「世界初」って。なひさん？

• 学校で教えた (世界初)
• 雑誌に連載した (世界初)
• 学会発表した
• 業務で使った

仕事で使う

体験談: 業務の支援ツールとして

なぜアプリも Ruby？

• トラブルシューティングする‘気になる’
• 非プログラマ向けに重要; 使いものになる

業務とは

• 似た「ようなこと」の繰り返し
  • いわゆるワークフロー
  • 同じようで、微妙に違う。
  • ローカルルールが山ほど。そのなかでエントリーもたくさん
• 隠し事が多い
  • インターネットを通せない
  • 権限にうるさい
  • 「決まりですから」／危険な操作をさせないことは実際に重要だし。
• 紙が重要
  • 紙になることが多い
  • スキャンデータとか Excel とか
• 少なくとも印刷できるようにはしておきたい。PC や端末に依存しないことはよいこと。
• 一覧性もあがる。
• プログラマが使うとは限らない
  • 英語ダメ
  • 日本語ファイル名当たり前
• 人名順序は辞書式じゃない！ 表示順はなんか謎でカスタマイズが必要。

使ってよかった Wiki⁷

• 「決まりごと」を書く
  • コピーが無いのがいい
  • 「決まりごと」といっても変更は出来ないと
• 「起こったこと」を書く
  • コマンドラインの記録とか，議事録とか
• チケットシステム ←これは無いと仕事にならない

Wiki の導入

• Office にすると正解 (最新版) がどれか分からなくなりがち。
• tDiary のカテゴリ機能は便利。
• でも Wiki は一般の人には割と敷居が高い。記号を使うのが大変。
• まずは大量に自分で書く。書く際の決め事は (ゆるくていいから) 決めておく。
• 無理に index を作らないこと。‘ある程度は’淘汰に任せるほうがよい。
  • 新規ページがいきなり作れるタイプの Hiki⁸ とかは手動で一覧を作りたい。

Wiki のルックス重要

• Hiki のテーマ、流通しているものは、ちょっと合わない。会社らしさ (CI⁹ とか) を反映させよう (会社のレターヘッドとか入れると効果的)。
• 封筒や PowerPoint のフォーマットに合わせるとか
• 印刷用スタイルシートも用意する→紙にも反映しやすい。

Wiki に欲しい機能

• タグ − ラベル貼りたい
• テンプレート − 定型が山ほどある
• ログイン − 署名したい (ルール化では不十分)

チケットシステム

• たっぷりつかってる
  • 影舞¹⁰は本来バグトラッキングシステムだが、テンプレートの「バグ」を「案件」に置き換えて利用
  • 影舞.gsub(“バグ”,”案件”)
• ワークフローの進行を記述。
  • 区切り区切りでチケットを発行する
  • ステップ一覧表
  • やりとりにも使用する
  • 可視制御・編集制御
  • 管理機能が簡潔かつ充分で、表示順序を制御できるのもうれしい。
• 一番最初のエントリを「おしらせ」に
• ルックスは絶対カスタマイズすべし。違う顧客のものに入れ替わったりするかもしれないので。
  • 本家の影舞に会社のデータ入れそうになったり w
• 250 エントリー／月
• ちょっとハック

Ruby アプリの問題点

• 探しにくい (じつはアプリの RAA エントリはそんなに多くない)

 Application 450 <<< Library 955

• 影舞とか howm とか portupgrade とかエントリされてない
• 商用 OS にパッケージされている Ruby は微妙に古い。1.8.1 と 1.8.2 だとライブラリ数ちがう。shim 必要か！？
• →客先で野良ビルド。で upgrade hell…

まとめ

• クローズドならではの制約
• もっと使おう。

Q&A

C (かずひこさん)

タグもテンプレートも、結構前から Hiki では使えます。

前田修吾「Rails によるメタプログラミング入門」

スピーカー

前田修吾氏 ((株) ネットワーク応用通信研究所 主任研究員); mod_ruby など、Ruby の標準添付ライブラリの開発者です。

時間

17:24〜17:54

セッション概要

Ruby の暗黒面を探求 (話題の Rails を題材に)

講演資料

http://shugo.net/tmp/metaprogramming.pdf

• メタ度 ★★
• DSL 度 ★★★
• おとうさん度 ★
• 同姓同名 Rails で注意度 ★★
• Ruby の闇がというより一部の発言が度 ★★★

自己紹介

• Family/Given 順が統一できなかった。これが Ruby Quality なのかな
• Scheme と同い年
• リクエストが有りましたので。
• 在りし日の JavaHouse-Brewers ML で regex 投げたら OO らしくないって恩師が
• クラックされたりとか。
• いきなり終わったり
• mod_ruby, eruby, ximapd/Ruby アプリ Ruby による (ママ)

目的

• Ruby を肴にメタプロについてお話

RoR

• 生産性 Java×10！「うそですけど」。
• 15 分でできる！「ぜったいめちゃめちゃ練習してですけど」。
• ruby-lang.org の before/after ちょっとバタくさいですが
• コンテンツが問題。協力者募集。
• 開発者のルックスがよくて matz がどうとはいわないけど キャッチーさでは……
• なにより Rails is fun!
• フレームワークってハリウッドの原則 “Don’t call us, we’ll call you.”
• フレームワークは使い方を強制されるので楽しくないのに Rails が fun なのは、Ruby が fun だから。「予定ではここで拍手があるはずなのでしたけれども」
• さらに meta programming が fun だから。

メタプログラミングとは

• メタ言語
• メタ SF
• メタミステリ¹¹
• メタリカ
• 自己言及的 (コード生成¹²、マクロ、テンプレート……)。「プログラムを扱うプログラムのこと」。
• DRY。生産性向上。たのしい。
• 副作用あり。ハイリスクハイリターン
  • ソースが読みにくい (正直 Rails のソースも……)
  • 実行効率が悪い

Rails に学ぶテクニック

• コード生成。Rails の scaffold が「10 分でできる……」を実現。べつに Ruby に特化した話ではない。
• blade テクノロジー的アプローチ。きっと中身は heuristic なんだろうなぁ
• DSL¹³
  • DSL + コード生成は、パワーのない言語で使用。必ずしも静的型付とは限らず
  • 言語内 DSL¹⁴ は、汎用言語で DSL を実装したもの (秀丸みたいなのではなく)。 Lisp のマクロ¹⁵。C++ のテンプレート等。
  • Ruby ならブロック使う。例: Builder テンプレート
  • Ruby ならあとはクラスメソッド。例: アクセサ (attr_reader, has_many)
• 脱線
  • has_many で find 呼び出すと配列との差が浮き彫りに。detect 使う→collect 派が拡大すると。
  • HasManyAssociation ……正規表現を実行して、該当しないものをクラスから削除してる
  • method_missing で処理。一見配列に見えるけれども、実は委譲の結果配列ではなくなっていたり
• eval
  • Ruby はコードを扱うことはできない (コードそのものは object ではないので)
  • 代わりに文字列をコードと見なして扱う
  • 動的にメソッドの追加ができる
  • eval power: eval の種類が 3 つもあるのは Ruby だけ！ (instance_eval, class_eval, module_eval)
  • Rails では eval を多用 …… 429 箇所！
  • $SAFE=4 でもセキュアとはいえないので、いいにくいのですが、使えません
  • 2.0 ではさらに eval が遅くなる…… eval は使うな？
• 標準クラスの拡張 (Ruby では既存のクラスを後から拡張できる)
  • active_support/core_ext
  • プラグイン。ダブルディスパッチを使用 (append_features)
  • 想定動作が変化してしまうので驚き最大
  • Rails なしで Ruby は使えますか？
  • jcode.rb 問題 (jcode.rb は String クラスを再定義するのでふるまいが変わってしまう。要注意)
• マクロ (Lisp にあって Ruby にはないもの): Ruby ではブロックや Binding.of_caller で代用。
  • って後者は Ruby 本体には採用されてないじゃん！ Rails は提供している。
  • 継続と set_trace_func を使用、行ったり来たりしてる。breakpoint でしか使ってない
• 「用量・用法を守って正しく使いましょう」