かたつむりは電子図書館の夢をみるか このページをアンテナに追加

2010-09-19

[][]「ウェブアクセスの自動化と業務妨害について」:第7期デジタルフォレンジック研究会主催講演会/情報ネットワーク法学会 第2回「技術屋と法律屋の座談会


岡崎市立中央図書館向けのクローラーを動かしていた男性が逮捕された事件、いわゆるLibrahack事件について、図書館業界の観点からの問題点の指摘と行うべき対応については先日、当ブログでも言及し*1、また図書館問題研究会からの声明もありましたが*2

Librahack事件は図書館の問題としてだけではなく、技術者と社会、中でも司法法律家との考え方の違いの問題、としても大きな注目を集めているように思います*3


昨日はその「技術屋と法律屋の問題」という点から議論が行われた、デジタルフォレンジック研究会と情報ネットワーク法学会共催のイベント、「ウェブアクセスの自動化と業務妨害について」に参加してきました。


テーマ:ウェブアクセスの自動化と業務妨害について

 インターネット上のウェブで得られる情報を便利に使うために、アクセスを自動化することが考えられます。しかし、それによって、ウェブサーバに予期していない負荷をかけるなどした場合には、その行為が業務妨害と誤解を受けてしまうかもしれません。

 実際にも、岡崎市立中央図書館の利用者が同図書館ウェブサーバへのアクセスを自動化したプログラムを作成してアクセスしたことにより、業務妨害罪の容疑を受けてしまった事例があります。

 この座談会では、ウェブアクセスの自動化と業務妨害との関係について考え、業務妨害を意図していない何らかのアクセスであっても、それがウェブサーバに障害を発生させる可能性があることを前提にして、アクセスする側が注意しなければならないことと、サービスを提供する側が注意しなければならないことについて、パネリストと会場参加者で意見交換をします。


以下、いつものように参加記録メモです。

例によってmin2-flyの聞きとれた/理解できた/書きとれた範囲のものですので、ご利用の際はその点ご理解いただきますようお願いします。

また、間違い等見つけられた場合はコメント欄等でご指摘いただければ幸いです。



はじめに(司会:日本ヒューレットパッカード佐藤慶浩先生)


岡崎市図書館時件の技術的論点整理(京都大学、上原哲太郎先生)

  • この事件についてはTwitterを中心にボランティアが事実を取材している
    • ここではその中でも中心的に活動している杉谷智宏さんのスライドに基づいて説明する
    • スライドリンク:no title

  • 発端・・・図書館システムが使いにくい
    • 岡崎市図書館のwebページが不思議な構造になっている
      • 新着図書ページがあるにはあるが、どう考えてもユーザにとって嬉しくない構造になっている
      • 項目順・過去3カ月の受け入れ分が、分野別あいうえお順で並んでいる
        • 毎日、毎週行く人は今週・今日入った本を探そうと思っても、毎日眺めて差分を取るしかない
    • 「これは使いにくい」というので、毎日、新着図書ページを自動取得して、差分を自動で取得しようとした

  • プログラムPHPで書かれた簡単なもの
    • 負荷がサーバにかかりすぎないように、1冊分データをとると1秒のウェイトを置いていた
    • 新着資料ページには入荷日が書かれていなかったので図書1冊ずつデータを取得
    • ちなみにLibrahack氏は月に100冊近く借りるヘビーユーザ




  • 対策がうまくいかないので警察に相談
    • ログを見てLibrahack氏を特定、被害届を出すよう要請
    • Librahack氏が逮捕され、20日間の勾留の後、起訴猶予

  • 技術的な問題点
    • MDIS・・・データベースセッション数がすぐに溢れる
    • クローラ・・・Cookieを処理しないことは問題ではない/robots.txtはルールではない。Macに入っている標準プログラムrobots.txtは見ない
      • クローラを作った人はUser agentに連絡先が残るようヘッダーに入れようとの紳士協定があるが、それは行われていなかった。ほとんど知られていなかったから?
      • Librahack氏のエラー処理が簡単。エラーが起きれば止まる構造になっていれば違ったかも? しかしエラーはサーバ障害以外にも起こりうるのでトリッキーな処置を取るべきか、という気も

  • 質疑:
    • 佐藤先生:ここから先はLibrahack事件そのものでなくここから教訓を得て今後、どうすればいいかという話に。何か技術的なご質問があれば?
      • 特になし
    • 佐藤先生:「DoS攻撃」などの言葉も使われていたが、短時間で重たい処理が必要なことをしていたわけではない。結局、1個処理を受けたらその処理に対応するプロセスを消さなければいけなかったのにプロセスを残してしまっていた。Wordを開いて閉じるたびにバックにWordがいる、あるいは100回ファイルを閉じたり開いたりしたらバックにWordが100個いたようなイメージ。それが積って動かなくなってしまった。
    • 佐藤先生:従来、発見されていなかったのは図書館へのアクセスがそんなになかったせい?
    • 上原先生:Googleクローラが来ると落ちることは認識して対応していたので、問題は発見されていたのではないかとの指摘もある。
    • 佐藤先生:この件でLibrahack氏が意図的に業務妨害したのではないか、と疑われて逮捕されてしまった。この点について石井先生にご解説いただいて、「法律的にはこういう解釈だが、技術屋さん、この問題を法律家はどう考えればいい?」という問題提起をいただく。


ウェブアクセスの自動化と業務妨害について:法学から情報技術に対する問題提起(千葉大学、石井徹哉先生)

  • なぜ犯罪として検挙されたのか、の解釈論的枠組みを話したい

  • 今回は業務妨害罪ではないか、ということで逮捕された

  • 裁判所の解釈では、業務妨害は業務を妨害するような偽計・威力を行使すると、業務が妨害されなくても適用される
    • サーバが落ちることは業務妨害罪においてmustな要件ではない
    • 電子計算機への業務妨害については刑法234条2が使われるが、これは手段が限定されている
      • 物理的な損壊、誤った情報や不正な指令など
      • 通常のDoS攻撃も該当しない
      • 通常のDoS電子計算機に大量の指示を与える威力の行使、ということで威力業務妨害とされることが多いが、今回は偽計だった

  • 「偽計」の概念は曖昧・・・
    • 非公然に変なことをするとたいがい偽計になる。機械に対する場合も同じ
    • Librahack氏のプログラム自体は正常なものだが、その正常な要求によってサーバ内の処理が変になった。そこで機械の処理を誤らせた、ということで「偽計」としたのでは
    • 逮捕した側も通常のDoS攻撃ではないことを理解して偽計を適用していた。わかっていたのではないか

  • 問題・・・業務妨害罪は故意がなければ成立しない
    • 故意は内心の問題。外見的にそういうことをしていれば逮捕は可能かも知れないが、受け手の側になんらかの故意を疑わせる事情があったから立件されたのではないか
    • たまたまそう見えた、不運と言えば不運かも知れないが、図書館やシステム側の対応にさらにLibrahack氏が対応したことが不幸を生んだ可能性もある

  • 気になるのは・・・プログラム自体が有害あるいは悪として客観的に認定できるのか
    • これまで、どんなものが有害なプログラムで他はそうじゃない、ということを、個々の説明はあっても体系的に成立させてこなかったのではないか?
    • ある人が図書館システムの中身と問題を知っていて、あえて同じプログラムを実行した場合は故意がある、となる。それとLibrahack氏はどう区別できる?
      • それをソフトウェアの側で区別できるのか? それができない、となれば立件もやむなし、との評価もありうる
    • 被害者の側をどう見るのか?
      • 従来、コンピュータ犯罪サイバー犯罪における情報技術の役割は行為者の行動の足跡を中心に証拠を集めてきた
      • 今回はそれぞれのプログラムがどういうものだったか、技術的なことがわからないと行為の全貌がわからなかった。これが今回の事案の問題提起の大きなところでは?

  • 佐藤先生補足:
    • 今度は技術屋さんが「?」と思っていそうだが、Librahack氏の件でも、どちらかと言えば技術屋が気にしたのは逮捕・勾留されたことと思う。そこについて石井先生に教えていただこうと思う。
    • 素人ながらにステップを考えた:
      • 捜査過程で事情聴取、逮捕・勾留、起訴/不起訴、裁判となるのだと思う
      • 技術屋としては逮捕・勾留とはどういうことかということで話題になった。結果論としてはDoS攻撃ではなく設計の問題とわかったわけだが、今回は「起訴猶予」として釈放されている
        • スライドにもあるが、逮捕が間違っていたとなると名誉回復を誰かにして貰えないか、という境界点が。本来、事件ではなかったのに逮捕されたのだから逮捕したことそのものを謝ってもらわないと、と思う。
        • 法律家さんの境界点は、裁判で無罪の人が有罪になったときには名誉回復が必要なレベルと言う境界点があるよう。あるいは起訴までしたら、と思うよう。捜査過程で逮捕・勾留があったことは「違法ではない」という。不適当ではあっても。
        • ここの境界線の意識がお互いに違っているのではないか、と考えている。一般人は「逮捕・勾留は間違いでした、ごめんなさい」と言ってほしいと思うわけだが、法律家さんとしては法律として考慮する内容ではない、となる。起訴より先に進まないものは法律は考察しなくていい、との考え。
        • ここの差は認識しないといけない。会場でも逮捕・勾留され、釈放の理由が「起訴猶予」となれば「許してあげるよ」ってことで帰って来たように思ってしまうのではないか。しかし実際には捜査に必要なこと、と考えられることもあるらしい。このあたりの解説を。

再び石井先生
  • 法律の建前で言えば、逮捕されようが起訴されようが犯罪ではない、という建前
    • 世の中が建前通りに動いてくれれば問題ないが、そんなことはない。
    • マスコミは逮捕されたら犯罪者のように報道する。それで悪い奴と思ってしまう。これは日本の社会の問題。法律が言ってもそうしない社会の問題
    • マスコミの事件報道をあらためない現状がある。しかも感情的に反発する。特定の人を擁護するわけではないが、不起訴処分になっただけで選挙に響いたりする
      • このような社会がそもそもおかしい、という疑問を持つ必要はある
  • ただ、実際問題、世の中の大半の案件は逮捕されるとほぼ有罪になっている
    • 法制度も部分的にそのように動いている。「起訴猶予処分」も容疑は濃いが起訴しない場合に多い。
      • 交通事故の被害者が軽傷のときなど。これは犯罪も成立している
    • 社会制度と、一部の実態を変える必要はある
  • 法律関係の建前としては有罪でなければ、という話

佐藤先生
  • この部分が座談会をやるまではわかっていなかった点
    • 法律家:「釈放されたんでしょう?」
    • 技術屋:「逮捕されちゃったんですよ!」
  • みんなが建前を理解してくれれば今回の場合も結果的には、設計のミスだったこともわかったので、建前の枠組みでは良かったね、となる
    • 勾留期間は大変なことでしたね、となる
  • 実際にはマスコミ等は逮捕の時点で犯罪者の可能性が高いと考える/道路交通法みたいなところでは実際にも、違法で逮捕したが起訴しない場合もある

質疑・意見交換
  • 佐藤先生:このあたりにご意見等、会場からあれば
    • Q: SIerの人間であり、ときに発注者になることもある人間。業務妨害という話になっているが、妨害された正常の業務の範囲はどこまで議論されているのか? サービス提供側が毎秒100万トランザクション来てもOKと思えば正常。しかし毎秒10万を想定して100万来たら妨害と思う。その点。サービス提供側はどこまでを出そうと思っていて、webサービスとして出しているのはわかっているが、それをクローラが見ることを想定したのか、という点は今までどのような議論が? 本人が意図しないものを妨害する、嫌だと言っていることをやったら妨害だと思うのだが、その点はどうなのか。
    • A(石井先生):妨害は生じていなくてもいい。実際には何かしら事実があったから対応するのだろうが、問題は、やった側がそれを知った上でやったのか。知らないなら故意はない。やった側が想定を知っているかどうかが問題。
    • Q:クローラを動かした側がわかったかどうか。サーバが受け入れるつもりがない容量が公知されているのにやったなら犯罪だろうが、今回の岡崎の図書館はそれを明示していたのか? システム作る側は発注元が「これでいい」と言った範囲で作っている。「これじゃもちません」と伝えても「お金がない」と言われればそれでやるしかない。バグは論外だが、「このサーバにこれ以上の負荷はかけないで」は宣言すべきなのではないか?
    • A(石井先生):この後の議論で。
    • A(佐藤先生):石井先生からも出ている疑問なので石井先生に答えていただいても(笑) 後の議論で。

  • 佐藤先生:法律家と一般人の感覚のギャップについてご意見・ご質問があれば。
    • Q:プログラマ。ずっとTwitterで#librahackを追っていた。ネットニュースで事件を知ったときは「DoSをやった人が捕まった」という話だったのが、色々な人が調べるうちに認識は変わってきた。私個人としては逮捕・勾留は大きくて、仕事ができない期間が20日生じるのは困ることだし、悪いことはしていないのに捕まってしまって、結果として有罪ではないというのは良かったと言えば良かったが、議論を追い掛けてやっとそれらの違いがわかった。不起訴なら私も「良かった」と思うだろうが、起訴猶予というのが議論を追っていて一番気になるところ。不起訴と起訴猶予のさじ加減を我々がどうにも出来ない、受け入れるしかないというのは、実態として起訴・起訴猶予がどれくらいの割合あって、それが実情としていいことなのかが気になっている。
    • A(石井先生):不起訴の中に嫌疑不十分、起訴猶予、がある。嫌疑不十分は容疑が固まらない、起訴猶予は容疑はあるが今回は起訴しない、ということ。起訴猶予検察になんらかの容疑はあるということ。検察は裁量の範囲内なら自由に決められるし、理由を明示する義務もない。検察審査会は被害者の側から起訴しなかった理由は問えても、被疑者の側からそれができない。それは制度上の問題。個人的にも起訴猶予はおかしいと思っているが、言ったもの勝ちの面がある。検察官に広範な裁量を認める現状の制度では追及しがたい、というところにも問題が。

    • Q:フリージャーナリスト。なぜ弁護士がつかなかったのか。弁護士がつけば20日間の勾留までいかないで、勾留は証拠隠滅と逃亡の疑いがあるからそうなるので、弁護士を断ったというのはご自分で勾留期間を延ばしたようにしか思えないのだが。取材を申し込んでも本人が応じて下さらないので事情がわからないのだが。
    • A(上原先生):伝聞だが、業務妨害罪で5年ないので国選弁護人はつかない。国選弁護人は懲役5年以上じゃないと駄目。当番弁護士との接見が送検前にはなくて、送検後は、弁護士に「頼むといくらかかるから、不起訴になりそうだし、自分で頑張って」と言われたとのこと。
    • Q:私は2回逮捕されたことがあるが、すぐに弁護士に頼んでいた。どうして頼まないのか、それで20日間勾留というのは気の毒だが短いようにも思えるので・・・マスコミに対するご批判もあったが、やっぱり警察からリークされると時間にもよるが、〆切が4時間くらいの間に記事を書くので、裏が取れない。これは警察の2課の案件なので、課長の発表と課長補佐の話くらいで記事を書いてしまう。マスコミ報道が悪いと言われるが、ストレートってそんなもの・・・
    • A(石井先生):弁護士にもよるが、弁護料20〜40万円、人によっては100万円。それを負担するかどうかの個人の判断にまで立ち入るのは論外では? マスコミ報道については、「しょうがない」と考えることが駄目。ストレートニュースで流すというのは警察発表の大本営マスコミが警察の広報機関になり下がっている。
    • A(佐藤先生):今のは売り文句に買い文句もあるだろうが、今の質問者ほど、一般国民は逮捕されたときの対応を知らない。大方の技術者は自分が逮捕されたときにそんなことはなかなか思い浮かばないだろうし、捜査官は調書を取ることを最優先でにこやかに、なごやかに対応する。そこで金を出して弁護士を、とは気づかないかも。全ての方がすぐ弁護士を、という認識はないだろう。

    • Q:ソフトウェアエンジニアリングに携わっている。起訴された側の立場で議論されているが、裁く側の立場として、裁判員裁判にこの手の案件がかかることはある?
    • A(石井先生):法改正されない限りない。
    • Q:システムを作る際、運用する際、両面から気になるのだが。非常に不安になるのは警察の捜査資料が完全にクローズドで、外から集めた事実からは本人に故意がなかったことも、逮捕がいきすぎとも直感的に思うだろうが。同じような議論が捜査の過程で緻密に解析されたのか? 法律専門家は携わったろうが、技術者の専門的観点から解析したり分析するプロセスは皆無だったのではないか? さらに視点をマクロに切りかえると、そもそも岡崎の図書館に対して強い怨念を持っていたとかいうバックグランドがあったなら別だが、本人はこのようなサービス停止をしてしまって得た利益があるのか。サービス提供側の岡崎市図書館はサービス停止自身を警察に通報するような重大な業務と判断したことは適切だったのか。そのあたりが問われないのは不自然。
    • 佐藤先生:技術的なボーダーラインは今後のディスカッションで。捜査の舞台裏は推定は出来るが、悪い人探しをするのは今回は控えたい。結果論として色々なことはわかったが、逮捕の時点でわかっていた人はいない。ベンダーはわかっていたんじゃないの、とみんなで苛める雰囲気だが、悪質な意味での隠ぺいがあったかは難しい。悪者探しはやめたいが、どういう技術基準で、というところは後で議論を。

    • Q:元IT記者、今はwebでITについて書いている。先日、上原先生から朝日新聞以外にももっと報道を、という話もあり、またマスコミの責任についての話もあったので。この話から学ぶべきことは同じことが2度と起こらない仕組みを作ること。弁護士が入るかとか、警察の捜査を見えるかするとか、証拠を取ることの仕組み作りにしていかないといけない。この岡崎の方もそういうことを知らなかったのだと思うのだが、そもそも岡崎の図書館システムを設計した人が間抜けというか、税金で作っているわけで、その利用者の税金を納めている方。それなのに新刊図書を出てこないようなシステムを大量のお金をかけて作っている、その行政の感覚がそもそも問題で、問うべきはそこでは。ちょっと取材したが、千代田図書館やICチップでの図書管理等、新たな図書館新サービスについて対応しているし、海老名市図書館では図書館を充実することをマニフェストにしていた。図書館は市民の情報基地、開かれたものでなければいけないのに、自分が便利なように馬鹿げた作りにして、ベンダーの鴨になり、迷惑も与えている。これはマスコミとして絶対にたたかなければいけない、二度と出てこないようにしないといけない。Twitterのような市民のメディアで言われていて、大きなマスコミの論調に出てきていないことは、今のマスコミ、停滞して官の情報をそのまま流す取材に行かないマスコミの責任と、私を含めて強く思う。
    • 佐藤先生:改善するべきとの意見として賜りたい。今回、マスコミ批判にするつもりはない。後半は悪者探しではなく、今回のことをきっかけに今後、どういうことをすると改善できるのか。一方で本当に業務妨害に至るケースもある。こういう技術的なことを法律家がどう考えていけばいいのか、という質問に技術屋がどう答えるかを考えていきたい。


10分間の休憩タイム


  • 佐藤先生:この後は石井先生から問題提起されている点を踏まえてディスカッションして行きたい。その前に、会場から図書館側に警察に相談する前にできることがあったのではないか、との意見があったが、歌代さんから相談先の候補についてご説明いただきたい。

インシデントレスポンスの視点で見る岡崎市図書館事件(JPCERT/CC、歌代和正先生)

  • JPCERT/CC概要*4
    • 1996年に正式な組織として成立
      • 2003年に法人化、現在に至る
    • 事件やソフトウェア脆弱性についての報告を受け付け、影響をなるべく小さくする活動
    • フィッシュング対策や国際組織CSIRTの事務局なども
    • 今回の件も可能性としてはここに相談していただいて対応する可能性もあり得た

  • CSIRTによるインシデント(事件)対応
    • 今回の事件の場合なら・・・
      • 図書館に利用者がアクセス、なんらかの障害が起こった
        • そこで警察に被害届を出したのでこじれた
      • そうでなければ・・・JPCERT/CC等のCSIRTに相談いただくと・・・
        • IPアドレス管理組織(ISP等)に問い合わせをする
          • ISPIPアドレスを誰が使っていたかの情報がわかる。その情報そのものはCSIRTには貰えない。個人情報なので。
          • その相手に障害を伝えてもらうことできる。ISPから当人(今回はLibrahackさん)に連絡が行く
          • Librahack氏なら、連絡があればプログラムを改修するなり対応して被害がなくなっただろう
      • こう流れれば特に問題もなく、事件として報道されることもない
        • こういうことのためにCSIRTが存在する
        • 今回は単純だが、国をまたがることもある。アフリカからのアクセスとかなら、日本のCSIRTから海外に連絡しそちらで処理をする
    • 誰が使っているかはわからないので当事者間で直接文句は言いづらいし、言語も違う
      • そこで間に調整期間が必要

  • 他にもやり方はある?
    • 直接ISPに苦情を言う。IPアドレスISPを特定して連絡すれば、サポートセンターから同じように連絡がいって、結果は同じようになったのではないか。
    • Webページで告知をする。「このようなアクセスで図書館システムに障害、心当たりがある人は・・・」など。後だから言えるのかも知れないが。

  • JPCERTはこういう場合、どういうことをする?
    • 報告を全て真に受けるわけではなく、ある程度検証する。ログ情報を貰って確認する等。今回の場合はシステムのログを見て、多めのアクセスがあるのでシステム障害があるのを確認した時点で処理をする
      • その際、故意・過失・事故の切り分けはしない。コストが非常に高いので、事実を確認したら調整に入る
    • 調整・・・一発で終わるかはわからないが、長引きそうなら当人同士でやり取りをしてもらう

  • ISPにおける一般的な対応
    • クレームを受理したら・・・(ちなみにCSIRTよりは被害者から直接が多い)・・・内容に従って対応
      • ウィルス感染の可能性:本人は知らないがDoS攻撃SPAMメールを送っている等
        • 本人はその事実を知らないのでソフトに対応
        • 「身に覚えがないならウィルスワームがいるかも知れないから駆除して」
      • 明らかな契約違反行為:SPAM業者、アダルトサイトの利用等
        • IIJの場合はサポートが武闘派なので、まずサービスを停止してから事後連絡をする。ユーザがそこまで多くないから出来るのかも?
      • 例外対応・・・そんなにない
        • 明らかに犯罪なら警察へ
        • あるいは病院へ
        • あるいはいい本のリコメンド。『ムー』とか。冗談です(笑)
        • システムがおかしいのでSIerと相談しては、というようなことはあまりない。
      • それ以外の場合でも・・・故意、過失、事故の判断はISPでもしない
        • ISPとしての判断はなるべく挟まず、定型的に対応するように
        • サービスを停止する場合も違法かどうかなどは判断しない。あくまで約款の違反を理由とする

  • このように、自分の意図しないことが起こっていることが当事者に伝わる
    • それで対応することに

  • 警察に行っちゃった後でも何か方法はなかったか?
    • 警察の捜査段階でCSIRTが依頼を受けて行動することは考えにくいが・・・
    • まず誤解:
      • JPCERTに相談すると警察に筒抜けになる・・・そんなことはない。警察に相談すべき案件と考えたら当事者に伝えてやってもらう
      • JPCERTと警察は仲が悪い?・・・そんなこともない。情報共有もある
      • 海外には警察と密接な関係にあるCSIRTもある。
    • 警察との連携例(1) JPCERT⇒警察
      • ある企業がDDoS攻撃を受けている、との相談・・・マルウェアによる攻撃と判明
        • マルウェアを入手、分析して、攻撃元のアドレスを特定
          • 海外数カ国のCSIRTに対応を以来
        • 当該企業経由で警察から情報提供依頼を受け、解析情報を警察に提供
    • 警察との連携例(2)警察⇒JPCERT(まれな例)
      • ある企業でインターネットに接続できなくなる障害発生・・・DoS攻撃と判明
        • ISPに連絡したところ、そのIPアドレスは使っていない、との返答
        • IPアドレスは詐称出来る。ISPに連絡してもどうしようもない、と判明
      • 県警に相談。すると担当者からJPCERTへ相談しては、との提案
        • JPCERTに連絡があり、一般的な情報提供等の対応
        • ただ、やり取りは途中で止まってしまった
      • その後・・・ルータフィルタしてアクセスをシャットアウトしているが、攻撃は今でも続いている
        • のんきな話だがとりあえず使えるからいいや、という

  • インシデントレスポンス的視点
    • 犯罪捜査的視点・・・やっている人の実態は凶悪犯、犯罪者、軽犯罪、いたずら、事故/過失、無実と分布
      • それに対する警察の対応・・・逮捕・勾留、叱責、注意、なにもしないなど
      • 警察としては犯罪者を取り逃さないことがやりたいのだろうが、漏れを出さないためにいたずら半分のところまで対応している
        • ミスや不幸な偶然が重なると、逮捕すべきではないような人にまでこれが及んでしまう
      • 悪さに応じて対応するのが難しいところ?
    • 他の皆さんの視点・・・無実の市民が冤罪によって逮捕・勾留されたという視点
    • インシデントレスポンスの視点・・・「問題があってそれを取り除きたい」
      • 犯人逮捕等は主眼ではない。今ある問題を解決したい
      • 無実、事故/過失、いたずら、軽犯罪、犯罪までまるっと対応する
      • 逮捕等の対応はしないし、実行者の切り分けもしない。犯人像等はどうでもよく、とりあえず当面の問題を終わらせる

  • 佐藤先生:警察ではない、他の選択肢の具体例と、その場合の対応の詳細について説明をいただいた。Librahackさんに弁護士を呼ぶ発想がなかったのと同じように、図書館もJPCERTというのは思い浮かばなかったから相談しなかったのだろう。実際にはこのような相談先もある、と踏まえていただければ。

ディスカッション1:アクターに関して

  • 佐藤先生:サービス提供者は幾つかに別れる。図書館に限らず一般化して議論したい
    • サービス提供者(発注者
    • サービス開発者(受注者1)
    • サービス運用者(受注者2)
      • ここで今回のことを活かしてできることはないか?
  • サービス利用者は・・・
    • 実際の個人利用者(今回ならLibrahackさん)
    • サービスを再利用して別のサービスを提供しようとする場合(個人ではなく業者等? Librahack氏は自分のサービスが便利なら開放するつもりはあったらしいのでこっちにも半分該当)
      • 具体例:カーリル*5。裏でデータを貰っているのではなくインターネット上で情報を取得している
    • サービスを検証する等の研究者webサービスの検証を考えている人。アクセスの結果webサーバが落ちた、等。再利用も想定しないし自分も使わない
      • 逮捕で一番ナーバスになったのはこの層? 自分の研究調査のためのアクセスで結果的にサーバが落ちたら逮捕されるのか、という

  • 佐藤先生:まずは提供者に絞って考えたい。今回のようなことからどういうことを考えられる? もし講師の方からまず、あれば。

  • 上原先生:サービス提供側もまた曖昧。今回の件でも、一般的にも、ITベンチャーのような自分で全部やっちゃうところ以外は、システム開発からサービスそのものまで責任を持てるところは少ない。サービス提供主体とシステムを作る主体に別れる必要があるが、一番困るのは、今回が顕著だが、システムを運用する、あるいはサービス提供主体が、あまりにもサービスの側だけからの視点から考えている。要求仕様がどうなっているとかを定義できないままサービス・インしていて、提供者がぼんやり考えているレベルを超えた要求に対してあたふたする。これをなんとかしてほどいていかないといけない。
    • 例えばだが、個別事例に戻って申し訳ないが、図書館のサービスのパフォーマンス指標はISOでもJISでも指標が決まっている*6。それに則ったことをきちんとやっていれば、ここまでサービスレベルに対して鈍感ではなかったはず。
    • システム開発者は、要求レベルが漠然としているとなんでもOKになってしまう。また今回の話で申し訳ないが、今回問題になったシステムがひどいシステムかと言えば、新刊図書ん部分は酷い。しかし図書館員には評判がいい。システム開発者は本当は利用者を見て商売しないといけないが、要求仕様に応じる段階で図書館員に対して作るので、図書館員の目につくところだけレベルが上がって、利用者に対する肝心な部分は要求もよくわからないのでおざなり。大変雑だが。
    • 先ほど会場からもお話があったが、運用者・開発者は利用者に「ここまでやりますよ」と提示する手法がないのかということで、一つ考えているのは、インターネットの原則は技術でできることは技術でできないといけない。テクニカルにレベルを提示できるなら提示すべき。webアクセスに関して言えば秒何回までOKという話はあってしかるべきだが、httpにそれがあるかといえばステータスコードで伝えるしかできない。
    • webのレベルならrobots.txtでクロール頻度も宣言できる。マッシュアップに対しては、性能の統一的な、技術的referがあるわけではない。ここは今後、問題になるのかも。

  • 歌代先生:違う視点から。一つ、今回のケースの問題は、いわゆる「お役所のシステム」だったことが不幸。最近、webサービスは「β」をつけるのが流行りだが、最近は未完成のものを公開してどんどんよくするのが流行り。webに限らない開発手法。自分でやっている限りはそれが出来るが、お役所のシステムは事前にスペックと発注書がいるし、バージョンアップや改修等の予算がない、ユーザの意見を取り入れて改善することがしにくい。受発注のシステムが現在の開発とマッチしなくなっている。
    • 民間では、下請けに開発は発注しているが、昔は請負でやっていたものを、最近は工数契約でやっている。「これだけの労働力をこの期間、確保してくれ」というもの。成果物による受発注契約じゃなくなっていて、そのあたりも開発のプロセスの変化に従って契約の形が変化している。

  • 佐藤先生:会場からどなたかご意見は?

  • 会場:仕事としてサービスを提供している。プログラムを実装して保守・運用し、家では利用や再利用をしている。今回の事件では「いきなり捕まっちゃったな」という違和感が強い。素朴な感覚としてはサービスの提供側も使う側もある程度の知識を持っていてやることである、利用側の過失で過大な負荷がかかっても話し合いでなんとかできると思っていたのだが、今回はそういうことが一切なく捕まったことが怖い。今後、クローラーを作るのは一般化するだろうし、小学生が夏休みに自由研究で作ったりすることもあるかもしれない。作る側の知識や配慮の欠如で過大な負荷をかけてしまうこともあるだろう。提供側として用意すべきこと、覚悟すべきことがいるのだと思う。図書館はそれがなくて、慌てて警察に相談してしまった。もうちょっと落ち着いていればまずISPに相談することができたはずだし、使う側としてもへまをしたらISPに怒られる、という意識だった。提供側として、広く公開するサービスにどのようなことがありえて、その時に対応すべきことをきちんと決めて持っておくことが必要なのではないか。
    • 技術的な不安としては、提出したログが改ざんされる可能性もある。それで無関係な人が捕まる可能性もある。ログが証拠として使えるかも含めて、本来は知っておくべきことがあったのではないか。使う側も節度あるアクセスをする必要があるだろうし、お互い必要な心構えがあるのではないか。

  • 会場:システムを請負で作る側の立場。要求仕様をちゃんとしてというのもあるが、機能要件だけでなく非機能要件も決めて、それをきちっとテストしないと、今回はバグだったが、お金貰って作ったならテストしよう、と。閾値が100のものに100のテストしかしないってのもなんである。プラスアルファぐらいはテストした上で納めるべきでしょう。自分だったらそう作りたい。

  • 会場:開発のプロセスに興味があったので、コメントと言うか感想を。歌代さんがおっしゃるようにこれからのシステムはますます作りにくい。固定的な発注・調達の世界は終わる。図書館のシステムはこれから出てくることの兆しではないか。設計段階で難しいのは、どれくらいのサービスレベルでユーザに満足して貰えるかの設定が、初期の設計段階では見通せなくなってきた。ユース・ケースをどれくらいに想定するかということだが、昔の事務システムみたいに利用者を開発側が強制的に決められない。不特定多数の人がどんな場面で使うものかわらかない、となるとユース・ケースの見通しは不可能。そうなるとソフトウェアPDCAサイクルで不完全性をどんどん埋めるサイクルを取らざるを得ない。そういう視点でシステムを見ると、ユーザが不満を持ったときに投げ彼られる窓口があったか。開発者には、要求のどこを直せばいいかというようなことの意識はあったか。納めて終わりじゃなかったか。メーカも、ユーザを固定的にモデル化してしまっているが、その情報を収集する視点を持たないと、「まさかユーザがこんなところで不具合を感じるとは想定しなかった」ということはこれからは許されない。データを取りながら次のシステム開発に渡すことを考えないといけない。

  • 会場:ISP関連の仕事をしている。歌代さんのお話にもあったようにJPCERT等からご連絡いただけばIPアドレスから利用者に連絡をすることは通常業務としてやっている。今回の件や世の中のイメージとして、インターネット匿名で元をたどれないイメージが強すぎる。IPアドレスから見ればたどれるんだ、ということを世間の常識にするだけでも今回の件はだいぶ違ったのではないかという気がしてしょうがない。

  • 会場:行政書士。今の方のお話に反応するわけではないが、IPアドレスが完全に匿名ではないとの認識は広がってきている。どちらかといえばユーザでシステムを知らない人でも、ネットが逆探知みたいなことができる、というのはわかってきている。今回の件だと、利用者の予想される使用の仕方が、利用者側も技術を持ってきていて、こういう使い方をした結果起こったもの。サーバセッション情報が10分残るとか、サポートする側は大変だろうと思ってしまったが、それを10分見ている人はいないだろうから3分にしようとか、何回もアクセスしたら「待って」みたいなものを出せなかったのか? それは技術的には難しい? 匿名掲示板でも「何秒待って」は出るが・・・

  • 上原先生:もちろん出せます。作っている側の技術がそこに及んでいなかった。

  • 石井先生:大学で図書館関係のこともやっている。図書館司書と一般の利用者は意識が違う。学内で図書館でそういうものを作ってしまうと使いづらいものを作るので、必ず利用者テストをしている。図書館員は利用者とギャップがあるので、こういうことにもなっているのではないか。

  • 佐藤先生:アクターを切ると受発注問題にも思えるが、サービス運用者の問題等もある。いったん、今度はサービス利用側の視点で意見をいただきたい。Librahackさんの件に限ると狭くなってしまうが、利用者のマッシュアップ等の可能性も今後あるので、利用者側としてどのような観点があるか。それから研究者としては違う観点があるのか。ちなみにこの中で利用者の立場で、家でマッシュアップをやり始めている方はどれくらいいる? ・・・多数ではないが始まっている。逆に手を挙げた方で今回の件をきっかけにマッシュアップするときに注意していることなどあれば。

  • 会場:自分でプログラムを書いてやっていて、相手のサイトに「やっていいよね」も確認している。「こういうことをしたいので1秒1回いいですか」と聞いたり。サービス側が普通の事務員だと考えると、技術レベルはアクセスする側が上。だとすると最初に「やっていいよね」と聞くべきでは。

  • 佐藤先生:それで「困る」と断られたことは?

  • 会場:頻度を下げて、と言われることはある。「行政としてその使い方は想定していないが、この頻度とこの時間帯なら影響ないしいいよ」というような。

  • 佐藤先生:この辺、研究者とはまた差異がある。検証する人はいちいち運営側に聞かないといけないのか、とナーバスにもなっている。

  • 歌代先生:利用者の観点だと、自動化をどこまでやっていいのかの観点はある。それができる人と出来ない人で格差ができる。できるひとは誰より早く新着図書を借りられる。電車で走ってきた若者に先に座られたような気分。提供者としても他の人のことを考えてやめてくれませんか、というような意識があるのではないか。今、すごい微妙な、移行期間中なのではないか。利用する側も提供する側も意識して。「できるからやればいいじゃないか」ということだと時間外取引みたいな感じになるのでは?

  • 佐藤先生:会場には研究者はいない? 研究者の方にはびっくりさせただろし、第1回では逮捕・勾留はしょうがないと法律家に言われて、高木先生は相当な作業量をかけてサイトの状態を確認したとのこと。ただ、研究者がどういう注意をしなければいけないかは研究者の間でも考えていただく必要がある。今回のように、毎回その状態を調べることはできないだろうし、研究者としてはどうしましょうか、と。カーリルの場合にはどこかで今回のLibrahackさんの場合は個人で、IPアドレスが変化したので攻撃の嫌疑がかかったのではないか、としている。カーリルは常にIPアドレスはカーリルのドメインなので嫌疑がかからなかったのかも知れない、としている。そういうところをどう考えるのかが次の課題ではないか。Librahackさんの場合は他意はなくいくつかのIPアドレスを使っていただけらしい。個人で利用する場合は注意すべきところかも。
    • 利用者の間では自動化をする方はまだ多くはないようだし、やる人はリテラシーが高い人でもあるようなので、その中で注意をしていくと。あるいは事前に連絡したり、ドメインの中で誰のアクセスかを明示したり。もちろん全員がそれができるかと言えばできないだろうし、そこをどうするかは考える必要がある。


ディスカッション2:ソフトウェアに対するフォレンジックの課題


ソフトウェアに対する技術的評価に対する理論的枠組み
  • 石井先生:ソフトには有害性がない、ということを言いきってしまう方が要るが、それは本当に言い切れるのか、言い切れるとしたらどう担保しているのか。

  • 上原先生:まず最初のお話、ソフトウェアの技術的評価について。今、デジタルフォレンジックの世界では改竄がされていないことをどう保証するか、をかなり議論して、相場観が固まってきている。ソフトウェアそのものについては、ここ数年、4〜5年でソフトウェアフォレンジックという名前で固まってきたいる。ただ、あまり流行っていない。
    • ソフトウェアフォレンジックでは、例えば制御システムで大きな事故が起きて、その制御でソフトウェアが大きな役割を果たしていた場合。例えば車の暴走のときに、ソフトウェアをちゃんと見ないと法的責任がわからない。そういう部分での部門はある。しかし意外に流行らない。
    • それより良く出てくるのはソフトウェアのコピーの発見。ビジネスになるので、「ここはここからのコピー」というのを特定する学問として出てくる。

ソフトウェア害悪性・有害性に対する評価の可能性
  • 石井先生:刑事事件では証拠度をどう扱うかが問題になり、そこでは科学的証拠も扱える。そこには理論的裏付けが必要。現在のソフトウェアの業界にはそれはあるか? 個々の技術者が突っ込みを入れてはいるが、個人の意見に過ぎないのかも知れない。それを理論的枠組にできないと、技術的なものは証拠に使えない。
  • 上原先生:ソフトウェア害悪性についてはニーズの話で、そろそろやらないといけない。ウィルス作成罪の話もあるが、「そのウィルスは本当にウィルスか?」という話をするときに議論になる可能性がある。一般論としてプログラムを見て判断できるかと言うことだが、個人的な感覚としてはかなり可能性はある。プログラムを見ればプログラマが何を考えていたかは雄弁に語っている。ただ、これは経験知なので理論的に体系化できるかはわからない。ただ、今回のプログラム岡崎市図書館のMDISのシステム)の中の以下の2行は、大変雄弁。

'エラー対策?

On error Resume Next

  • 上原先生:この2行でプログラマの程度が「ああ・・・」とわかる。一般的にも汚いコードはレベルが低いし、「カッコイイ」アルゴリズムは頭がいい。言語の選択でもお里がわかる。この経験知を、体系化できるかはしんどいかもしれない。

フォレンジックの原点:科学的知見の法廷証拠への活用
  • 石井先生:捜査・訴訟の段階で技術者の知見をうまく取り入れるには、それを機能させるにはどうすればいいのか? 責任能力については医学的見解が定まっている。そういうものが技術的なものにもいるのでないか、そういう時期に来ているのではないか。警察の側はどうしてもログを見るわけだが、それぞれのプログラムがどう動くかを検証することでわかることもある。そういうことがうまくできればよりよい社会にできるのではないか。

  • 上原先生:フォレンジックの原点についてだが、JPCERT/CCと警察の間ではやり取りがあることもあったわけで、ゼロではないが、確立されていない。確立されていないのは技術の問題ではない。交通事故、医療事故もそうだが、専門的知識がないとそれが正当なのかわからない話について、本当は専門家司法コミュニケーションが必要なのに確立されていない。それがソフトウェア分野にも必要なのだがまだ整備されていない、ということなのだと思う。

  • 佐藤先生:ここで会場の時間切れ。尻切れトンボで申し訳ないが。また別の機会を設けて、こちらの件は・・・石井先生からすると「なんのために来たんだ」と言うこともあるかもしれないが・・・継続的に議論していきたい。



イベントの趣旨としては一番最後の、「ソフトウェアに対するフォレンジックの課題」という点を最もディスカッションしたいところだったのでしょうが・・・自分としてもそこを一番期待していたので、尻切れになってしまったのは残念。

各々の議論も大変面白かったのですが、会場の時間設定が思った以上にタイトだったということで、先にそちらの議論をしておいた方が良かったかも知れませんね・・・と、これも結果論ですが*7

ぜひ、引き続きのイベントにも期待したいな、とかなんとか。


それにしても、時間配分の狂いの一因は思いのほかに議論が盛り上がったというか、会場でも特定の方だけではなく様々な方が発言されていたので・・・主には技術者の方が多かったかと思いますが、ジャーナリスト行政書士の方もいましたし、やはりLibrahack事件に関連しては多くの方が注目し、注目するだけでなく自分の意見を持っていて、発信したり議論したいことがそれぞれあるのだな、というのは強く感じるイベントでもありました。

言い換えれば、「今回はここ!」というのをかなりはっきり決めてかからないと、短時間で深い議論をするのは難しいとも言えるのかも知れません。

繰り返しにもなりますが、最後の石井先生と上原先生の議論をさらに深めていける場があるならまた是非参加してみたい、と思います。

*1 Librahack事件について:あるいは、図書館と利用者の関係と、僕らに出来るかもしれないこと - かたつむりは電子図書館の夢をみるか

*2ともんけんウィークリー: 岡崎市立中央図書館利用者逮捕勾留事件について(声明)

*3:他にも行政の問題とか受発注の問題とか色々視点はあって、それで議論が複雑になっている面もあるかと思いますが

*4JPCERT コーディネーションセンター

*5カーリル | 日本最大の図書館蔵書検索サイト

*6:参照:CiNii 論文 -  図書館評価 : パフォーマンス指標と統計(<特集>情報活動と標準規格) 図書館パフォーマンス指標 JIS X 0812:2007(ISO 11620:1998) - 本:hontoネットストア

*7:会場はホテルの一室で、この講演会の後はどうも結婚式の二次会会場になるようでした。きらびやかな服を着た方々といつもどおりにジーンズによれた靴をはいた自分がすれ違う違和感・・・とか思いましたが考えてみれば自分は先輩の結婚式の二次会に似たような格好で行ったことがあったり

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/min2-fly/20100919/1284855069