ALIS勉強会−岡崎市立図書館のlibrahack事件を踏まえて、技術的な観点から / インターネット、コンピューターに詳しくないごくごく普通の人のために
先日、筑波大学にて"ALIS勉強会−岡崎市立図書館のlibrahack事件を踏まえて"を開催しました。
ALIS勉強会−岡崎市立図書館のlibrahack事件を踏まえて
日時：2010年10月27日（水）15:30-17:30
場所：筑波大学メディアユニオン3F共同研究会議室
（開催告知→http://bit.ly/barbTS）
そのALIS勉強会の記録を公開したいと思います。
いつものことですが、記録はhumottyの聞き取れた・理解できた範囲のものになりますので、ご理解のほどよろしくお願いいたします。
それでは、どうぞ！
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
注意
- これは、ただの学生が開いた身内による身内向けの（学生による学生のための）勉強会です
- 注目を浴びているトピックではありますが、学校で何人かで集まって勉強会をするような、そんな風景をイメージしてください
- ですので、ここに書いてあることのすべてが正しいとか、この解釈が良いとかを主張しているわけではありません。間違っていることもあるかもしれません。もし見つけたら、優しく学生に教えてくだされば幸いです
- ということを踏まえて、読んでいただければと思います
はじめに（有元さん）
- なんでこんな事件が起こってしまったのか
- 自分が図書館員だったら、どう考えるだろう
- 個人的には、システムが苦手だからと言って、業者任せにしてしまったからこの事件が起きたのではないかと思う。でも、「苦手だから」じゃすまされないこともある。
- 事件について、みんなと一緒に考えてみようと思った。
よくわかる岡崎市立中央図書館事件（池田くん）
岡崎市立中央図書館はRFID等も取り入れた、新しくてきれいな図書館。
登場人物
- 岡崎
- 警察
- 業者
- Librahack氏
事件の概要を聞いて
「設問１」
「Librahack氏のようなアクセスの仕方は特殊なのか？」
ここで、会場の参加者に設問を投げかけ、それぞれ自分の意見を答えてもらう。
- 特殊だと思う
- プログラムとか使ったらできるのかもしれないけれど、普段からしようとは思わないから（プログラムを使ったりしないので）特殊だと思う。
- 特殊だとは思わない
- ここの学類にいるから当たり前に見えてくるというのもあるが、Librahack氏の配慮などを考えると特殊ではないのかなと思う。
では、実際はどうなのか？
もう少し詳しく内容について考えていきます。
アクセスログについて（佐藤先輩）
- アクセスログとは
- 実際にボットはどのように使われているのか
何が言いたいかというと、プログラムを使ったアクセスというのは、インターネットの世界ではごくごく当たり前に行われているということ
2つ目の質問
「設問２」
「自分のアクセスが原因でサーバがダウンしたことを、プログラマなら気が付くべきではなかったのか？」
ほとんどの参加者が「そう思う」と回答
プログラマが気がつけばいいのはごもっともだが、そこには少し事情があります。
その「事情」を考えるために、以下でHTTPについて簡単に解説します。
HTTPとは何か（常川さん）
- HTTPとは
- Hyper Text Transfer Protocol
- HTMLなどをやりとりする会話のルール
- 普段の手順
- リクエスト：http://〜のページの情報をください！
- レスポンス：はい、どうぞ！
- なぜこんなルールがあるの？
- こういうルールを決めておかないと、やりとりができない。
- 日本のコンビニで、ヒンディー語で話しかけられても対応できないように、コンピューター上でやりとりするルールを決めておかなければいけない。逆に、これがあるからこそ、インドのページも見ることができる。
- いつもどういう風に使われているの？
- HTTPヘッダ：たとえば知識情報のページを見ると…
- ぼくたちは、必ずこういったプログラムのやり取りをしないと、Webページを見ることができない。
- こういうやりとりを、普段ウェブブラウザなどが隠れてしているので、自由にWebページを見ることができる。（それをユーザーエージェントという）
- リクエスト：GET / index.html
- GET = メソッド
- index.html = URL
- URL：何を
- メソッド：どうしたいのか？
- メソッドの種類
- GET - ××を下さい！
- POST - ××を作成/編集したい！
- HEAD - ××のヘッダをください！
- （他にもあって、全部で8種類）
- 今回の話では、GETになる。
- クロールでもボットでも、ブラウザでも、全部同じメソッドが使われている。
ステータスコードについて（池田くん）
- ステータスコードはたくさんあるのですが、そのいくつかを分かりやすくするために、寸劇をします！
ステータスコード劇場*2
今回は映像記録がないため、お見せできないのが残念です。
非常に面白い寸劇でした。
- 200 OK
- ラブレターを持って駆け寄り、「好きです、付き合って下さい！」
- 満面の笑みで「はい、喜んで！」
- 404 Not Found
- ラブレターを持って駆け寄り、「好きです、付き合って下さい！」
- 「私、有里じゃなくて有元なんだけど」どうやら相手を間違えたようです。
- 403 Forbidden
- ラブレターを持って駆け寄り、「好きです、付き合って下さい！」
- ラブレターを受け取り、びりっびりに破いて足で踏みつける
- 「二度と近寄らないでって言ったよね？」
- 500 Internal Server Error
- ラブレターを持って駆け寄り、「好きです、付き合って下さい！」
- 「えっ、ちょっと…どうしよう…」予期せぬ事態にテンパってしまい、思考回路はショート寸前
- 503 Service Unavailable
- ラブレターを持って駆け寄り、「好きです、付き合って下さい！」（1人目）
- ラブレターを持って駆け寄り、「好きです、付き合って下さい！」（2人目）
- ラブレターを持って駆け寄り、「好きです、付き合って(ry
- 「ごめん！ちょっと今… 返事できないの…」
- 「くそっ！」（遅かったか、的な意味で）
3つ目の質問
「設問３」
「とはいえ、特定サーバに負荷をかけるのであれば、事前に許可くらい取ってしかるべきだったのでは？」
会場に聞いてみると、意外と「そうは思わない」人が多い
- 許可を取るべき
- 新着図書がいつ入ってるかというのは、プログラムを作るよりも図書館に聞く、もしくは頼んでみても良かったのでは？
- 許可〜の話については、最初の「アクセスログについて」を参照
Webアクセスのしくみ（佐浦さん）
（注意）
この「Webアクセスのしくみ」については、「メリル方式」や「都度アクセス方式」等の言葉も含めてすべて、
高木浩光先生のブログ高木浩光＠自宅の日記 - 三菱図書館システムMELIL旧型の欠陥、アニメ化 - 岡崎図書館事件(7)を参考に作成させていただきました。
- 実際にLibrahack氏がアクセスしたときはどのような事がおきていたのか？
- ブラウザからWebサーバに接続する（アニメーションで説明）
- Webアプリケーション：Webサーバに置いてあるプログラム
- 都度接続方式
- ユーザー→Webサーバの接続：HTTP接続
- Webサーバ→DBサーバの接続：DB接続
- DBサーバでSQL（命令）を実行すると、検索結果（蔵書検索など）が返ってくる
- 応答が終わると、接続を切る
- 岡崎市立図書館の場合
- ブラウザからWebサーバーに接続するのは同じ
- ユーザーに結果を返した後も、WebサーバとDBサーバの接続が残っている
- この方式を仮に「メリル方式」と名付ける。*4→使わなくなったDB接続が残ったままになる
- 岡崎市立図書館の場合、何が問題だったのか？
- HTTP接続が切れても、DB接続は残ったまま
- DB接続の上限を超えると、（WebサーバもDBサーバも正常稼働しているのに）それ以降の接続ができなくなってしまう。（それ以降の利用者が、検索をできなくなってしまう！）
- この際返されるステータスコードは、先ほどもあった「500」（思考回路はショート寸前）
- 岡崎の場合、使わなくなったDB接続は10分たつと消える仕組み。
- なぜDB接続を残しておくのか？
- 前に使ったユーザーが、10分以内にもう一度使うと、早く検索できるから（？）残しておいたらしい。
- 上限はなぜ設定されたか？
- それぐらいだと正常に動くのでは、という見込み。
- でもメリル方式以外だと、上限を設定しなくても良い。
- クローラーの場合
- メリル方式の問題点
- 結果的に
- メリル方式で、クローラとCookieが有効なブラウザが混在した場合
- Cookie無効のクローラが上限数を超えた接続を残しているため、ユーザーのアクセスができなくなってしまう。
- 10分たつとセッションが消えて、それ以降に新しく接続して検索を行うことができるが、上限数を超えている間にアクセスしたユーザーは、DB接続ができなかったために、10分経過した後も接続できないままになってしまう。
- Q. 一般的にはどちらの方式が採用されているのか？
- 一般的には、「都度接続方式」の方が一般的
まとめ
- 開発されたシステムに、致命的な欠陥があったといえるのでは。
- 2005年（開発）当時でも、時代遅れ
- 他の図書館には、その欠陥に対処した修正プログラムを配布していたが、岡崎市立図書館には配布していなかった。
質疑応答
- Q. 図書館はなぜ最初に警察に相談したのか？最初から犯罪だと思っていたのか？
- Q. システム会社はどうすればよかったのか？
- パッケージとして運用も込みで売っているはずなので、もう少し適切な配慮をしても良かったのではないか。サービス業者なら、JPCERTのようなサービスを知っていたはず。いろいろな回避方法もあったが、ステータスコードは最後まで403を返さなかった。技術的なコミュニケーションをとるなど、もう少し穏便に済ませるような手回しが良かったのではないか。
- もう少し言及すれば、ログをちゃんと見ていれば、新着情報から蔵書検索にあたるなど、どんな行動をしているのか分ったはず。にもかかわらずこのようになったのは、まあログを見ずに、単純にアクセスが多かったから大量アクセスの攻撃だと判断したのでは。
- そういう行為を怠ってしまったが故に、結果的に、顧客を失ったり悪名高くなってしまったり、どちらにも悪い結果となってしまった。
- Q. 図書館員も技術に詳しくなければいけないのか？
- 実際図書館の人も、システムを導入するには仕様書を書く必要がある。仕様書をちゃんと書いていれば、「メリル方式」（造語）とかいうシステムにもならなかった。知識があれば、自分たちの業務をより良く遂行できることもできるのでは。
- Q. 他の図書館（のシステム）では何らかの対処をしていたとあったが。
- おそらくシステム会社の担当間で連絡がとれていなかったのでは。他の図書館でも事例があっても表ざたにはならなかったりなども。
おわり
勉強会の記録は以上になります。
重ねがさねではありますが、あくまで学生同士の自主的な集まりであることに配慮していただき、間違いなどありましたらぜひご連絡ください。
最後になりましたが、この勉強会を開催するにあたり、多くのサイトやブログなどの解説、情報を参考、引用させていただきました。
Librahack氏はじめ、参考にさせていただいたすべての方に、厚く御礼申し上げて終わりにしたいと思います。
ありがとうございました。
11/2 「インド語」から「ヒンディー語」に修正
*1:岡崎のWebページは、3か月ごとの新着図書をあいうえお順で掲載していたので、掲載日順の図書が分らなかった
*2:見ての通りですが、As Sloth As Possibleさんの「告白された時の正しいステータスコードの返し方」を実写化したものです。
*3:詳しくはCookie（HTTP Cookie）とは - IT用語辞典 e-Wordsを参照
*4:最初にも述べましたように、この「メリル（MELIL/CS）方式」は、高木浩光さんの造語で、ここの説明も全て、高木浩光さんのブログ高木浩光＠自宅の日記の「三菱図書館システムMELIL旧型の欠陥、アニメ化 - 岡崎図書館事件(7)」から引用させていただいています。
