大企業のほうが成長が遅いというけれど・・・

ビジネス

ちょっと前の記事になりますが、ちきりんさんの「2013-11-13」を読みました。私は中小企業と大企業の両方で働いた経験があるため、私の意見について書いておきたいと思います。

私も基本的にはちきりんさんと同じ考えで、大企業とベンチャー企業や外資系企業を比べたら、大企業のほうがビジネス分野における成長スピードは遅いと考えてます。ただし、ひとつだけ条件があります。それは、

「途中で脱落しないこと」

です。

私の場合、最初に就職したのはベンチャー企業（という名の中小企業）でした。その後、転職で大企業に入社しています。ビジネス分野における成長幅だけを見れば、最初に入社した会社のほうが会社の規模に関わらず確実に大きいです。企業規模は関係ありません。

私が最初に入社した会社は研修制度などが整っておらず、現場で様々な失敗を繰り返しながら勉強してきました。その分いろいろなことを経験させてもらえたことはとても良かったと思いますし、その時の経験は今の生活にも大きな影響を与えています。ところが、この会社で働いている時に過労でダウンしてしまいました。途中で脱落してしまったのです。こうなってしまうと、これまでの成長スピードがどうこう言っていられなくなります。生きることに対して、大変なエネルギーが必要になってしまったのです。ただし、脱落しなければ大きな成長を手に入れることができたと思います。そういう意味では、「途中で脱落さえしなければ」ベンチャー企業や外資系企業のほうが成長スピードは速いんじゃないかな。

大企業と中小企業を比べれば、大企業のほうが労働環境が整っている傾向があります。普通の体力と普通の精神力を持った人間が普通に仕事をしていれば、過労でダウンしてしまうことは中小企業に比べれば少ないです。これは、「そういう傾向がある」というだけで、大企業であれば長時間労働やサービス残業が無いということを意味しているのではありません。大企業であっても長時間労働が常態化している企業もありますし、大企業であれば部署によって文化が大きく異なります。配属される部署によっては中小企業以上の過重労働を強いられる場合もあります。ただし、そのような事態が発生する可能性は比較的少ないと思います。

学生時代に起業すれば、ベンチャー企業に所属するよりも速いスピードで成長することができるかもしれません。しかし、社会人経験のない普通の体力と普通の精神力を持った人間が、そのような環境下で脱落せずに継続的に成長できるかと言えば、かなりの疑問があります。

成長スピードよりも「収穫量」のほうが大事

私が大事にしたいと考えているのは、成長スピードよりも人生全体での収穫量のほうが大事なのではないかということです。

収穫量が何であるかは人それぞれです。生涯賃金を収穫量と定義する人もいれば、仕事を通して得られる満足感を収穫量に定義する人もいると思います。仕事はお金を稼ぐための手段であって、それ以外の分野に収穫量を求めている人もいるでしょう。ただし、自分の人生で何を収穫しに行くのかは、できるだけ早く決めたほうが良いです。そのほうが確実に収穫量は多くなるから。

きっと今の20代の人が定年を迎える頃には、定年になる年齢が70歳くらいになっていると思います。もしかしたら、定年制度自体が崩壊しているかもしれません。そのような世の中で、最初の5年とか10年とかで燃え尽きてしまう人生を歩むよりは、長期的な視野を持って歩んでいったほうが良いと思います。もちろん、収穫する目標を人生の途中で変更するのもアリですし、体力と精神力に自信があるのであれば、スタートダッシュで一気に収穫量を増やすという選択肢もアリです。

大企業を選択するほうが賢明かというと、そういうこともない

それでは大企業に入社したほうが賢明かというと、そうとも言い切れないと思います。

大企業に新卒で入社してきた方々を見ていると、「この会社以外では生きていけないだろうなあ」という若者が量産されています。これも、「そういう傾向がある」というだけで、大企業に入社した全員が成長スピードが遅いかというと、そのようなことはありません。そういうことではありませんが、所属している会社以外で通用する能力を身につけていないと、10年後や20年後に所属企業が事業不振に陥ったとき、生きていくのが困難になります。大企業とはいえ、永久に安定した経営が続けられるという保証はありませんからね。


ちなみに、私は一度脱落してしまいましたが、回復した後に引き続きIT業界で働いています。今でも全快と言えるほど回復はしていませんが、まあまあ普通に働けていると思いますし、今働いている会社をリストラされたとしても、まあまあ生きていけるくらいの仕事はできると思います。私の周囲には、IT業界の仕事に疲れてしまい、全くの他業界に移った人もいます。彼は転職先で彼女を見つけて結婚して幸せな家庭を築いていて、そのままIT業界で仕事をしていたら手に入れることができなかったであろう幸せな人生を歩んでいます。何が幸せに結びつくかなんて、わからないものです。

将来を真剣に考えることはとても大切なことですが、成長スピードばかりに囚われていると、意外な落とし穴に嵌ってしまう可能性もありますし、手に入れられるはずの幸せを逃してしまう可能性もあるので注意しましょう。

暗号化したパスワードが漏洩するワケ

IT

WEBサイトからのアカウント漏洩が頻発しているように感じています。最近の主流は、利用者のパスワード使い回しにより、あるサイトのアカウント情報が漏洩することで、別のサイトにも同じアカウント名を利用して不正ログインされるという事例が多いそうです。アカウント名をメールアドレスに利用しているサイトも多いですからね。
このような事例とは趣旨が異なるのですが、「ウチはパスワードを暗号化しているから、漏洩しても大丈夫！！」と言っている方とお会いする機会があったので、「いやいや、それは違うよ」という点について書いていきたいと思います。

「パスワードの暗号化」とは？

今回のエントリでの「パスワードの暗号化」とは、なんらかの仕組みを使って元のパスワードの読み取りを困難にすることを指します。

似たような結果を得られるものとして「エンコード」というものがあります。エンコードは、あるルールに従って文字を置き換える仕組みのことです。エンコードの例としてBase64エンコードというものがあり、例えば "abcdef" という文字列をBase64でエンコードした場合、"YWJjZGVm" という文字列に変換することができます。元の文字列とは異なっているため暗号化されているように見えるかもしれませんが、エンコードのルールさえわかってしまえば元のパスワードを読み取ることができるため、このような仕組みは「パスワードの暗号化」には含まれません。

「パスワードの暗号化」と言われている方式には2種類ある

「パスワードの暗号化」と言われている方式には2種類あります。ひとつは、元のパスワードに戻すことができない方式。もうひとつは、元のパスワードに戻すことができる方式です。

元のパスワードに戻すことができない方式は、「一方向ハッシュ関数」という仕組みを利用しています。MD5、SHA1、SHA256などの例があります。一方向ハッシュ関数とは、元となる入力に対して関数を適用すると、次のような性質を持った結果を得ることができるものです。

(1) 元のデータの長さに関わらず、同じ長さの結果が得られる
(2) 元のデータが異なれば、得られる結果は全く異なるものになる
(3) 元のデータが同じであれば、得られる結果は同じものになる
(4) 得られた結果から、元のデータを得ることはできない

このような性質を利用して、登録時に入力したパスワードを一方向ハッシュ関数を使って計算し、その結果をデータベースに保存します。上記(4)の性質によって、データベースに保存された変換後のデータから元のパスワードを得ることはできません。ログイン時には、(2)と(3)の性質を利用して、認証画面に入力されたパスワードに対して同じ一方向ハッシュ関数を適用し、その結果がデータベースに保存されたデータと同じかどうかを比較します。同じであれば認証成功であり、異なっていれば認証失敗です。


もう一つの、元のパスワードに戻すことができる方式は、いわゆる「暗号」の仕組みを利用しています。すごく簡単に表現すると、「鍵」を使って元のパスワードを読めなくする仕組みです。

鍵を使った仕組みでは、登録時に入力されたパスワードを、「鍵」を使って別のデータ列に変換します。このデータ列がどの程度強固であるかは、暗号化に利用するアルゴリズムと鍵の長さに依存しますが、適切なアルゴリズムと鍵を利用すれば、十分な強度で元のパスワードを守ることができます。その後のログイン時には、データベースに保存されたデータ列から「鍵」を使って元のパスワードに戻し、認証画面で入力されたパスワードと比較することで、正しいパスワードが入力されたかどうかをチェックしています。

どちらの仕組みを利用するべきなのか

私がこれまで仕事で関わってきたシステムでは、元のパスワードに戻すことができない方式を使う（一方向ハッシュ関数を使う）事例のほうが圧倒的に多かったです。そういう点においても、「パスワードの暗号化」には、元のパスワードに戻すことができない方式を使うべきだと考えています。

利用者視点でこの2つを見分けるには、パスワードの再発行をしてみると良いと思います。
もしパスワードの再発行をした時に、今のパスワードを通知する仕組みが備わっていると、そのシステムでは元のパスワードに戻すことができる方式を利用していることになります。（もしくは、全く暗号化していない可能性もあります。）

一方向ハッシュ関数を使ったシステムでは、パスワードの再発行をした時には、必ず新しいパスワードを設定しなければなりません。何故なら、システムで保存している情報を使って、元のパスワードを得ることができないからです。この点を嫌って、「どうしても元のパスワードに戻す仕組みを使って欲しい」という方もいらっしゃいます。

一方向ハッシュ関数の弱さ

パスワードを保存する時には、元のパスワードに戻すことができない方式を使う（一方向ハッシュ関数を使う）ほうが良いと書いてきました。しかし、この方式も適切に使わないと大きな弱点が発生することがあります。

例として、4桁の数字を使った「パスワードの暗号化」について取り上げます。
このようなシステムでは、図１のような表がデータベースに保存されているはずです。



図１．データベースに保存されているアカウント情報

アカウント "pucotan" のパスワードは、一方向ハッシュ関数によって "69aa50d0821a77410478ef06b174193c892c210509e13aeec8a8ae6a0225b42a" という文字列に変換されています。この状態では元のパスワードに戻すことはできませんから、パスワードの保存方法として適切であるように見えます。

ここで、一方向ハッシュ関数を利用して、"0000" から "9999" までの文字列を変換することにしてみましょう。この出力結果のサンプルを図２に示します。ちなみに、この10,000件のデータは0.05秒で作成が完了しています。



図２．一方向ハッシュ関数を利用した文字列の変換結果

ここで作成した10,000件の中から、"69aa50d0821a77410478ef06b174193c892c210509e13aeec8a8ae6a0225b42a" という変換結果の行を探してみましょう。これが図３です。



図３．変換結果から元のパスワードを探した結果

この図で示した通り、"69aa50d0821a77410478ef06b174193c892c210509e13aeec8a8ae6a0225b42a" という変換結果になるパスワードは、"4649" であることがわかりました。このような方法を利用することで、一方向ハッシュ関数を利用して変換したパスワードから、元の情報を得ることができるのです。

一方向ハッシュ関数のもう一つの弱さ

さて、図１の表をもう一度見てみましょう。パスワードの列が同じアカウントが存在していますよね。"pacotan" と "pocotan" です。これは "pacotan" と "pocotan" の二人が、同じパスワードを利用していることを表しています。つまり、どちらか一方のパスワードが漏れてしまったら、もう一人のパスワードも判明してしまうのです。

どうすれば良いのか

一方向ハッシュ関数を利用して変換したパスワードを元に戻すために、予め用意しておいた図２のようなパスワード変換表を利用しました。このような変換表の作成を困難にすれば、元のパスワードを得ることが難しくなります。

例えば、システムごとに固有の文字列（秘密の文字列）をパスワードに付加した後で一方向ハッシュ関数に通すことです。ここで秘密の文字列を "XYZABC" とすると、"4649" の変換後のデータは "ffd9c201da51f658349aa13c5f17e38383181d2b3d01d3aa88f6ecc585299685" になります。先程の "69aa50d0821a77410478ef06b174193c892c210509e13aeec8a8ae6a0225b42a" とは全く違いますよね。

この場合であっても、同じパスワードを設定しているアカウントで同じ結果になってしまうことは避けられません。これを防ぐには、アカウントごとに固有の文字列を付加した後で一方向ハッシュ関数を通します。このようにすることで、同じパスワードが設定されたアカウントであったとしても、変換後のデータは異なるものにすることができます。

まとめ

パスワード管理はとても難しい問題で、どのような方法を採用したとしても完全に守りきることはできません。「パスワードによる認証の限界」という点も指摘されています。
今回は一方向ハッシュ関数を使ったパスワード管理方法の注意点を指摘しましたが、鍵を利用した暗号化方式においても、利用方法を誤ってしまうと元データを推測することができてしまうという問題があります。
技術を利用する時には、「○○をすれば安全」という発想ではなく、その技術の限界を知ることと、正しい方法で利用するということがとても重要なことなのです。


新版暗号技術入門 秘密の国のアリス

新版暗号技術入門 秘密の国のアリス

クラウドソーシングサービスを発注側として使ってみました

IT ビジネス

もう数ヶ月前のことになりますが、クラウドソーシングサービスを発注側として使ってみました。クラウドソーシング（crowdsourcing）とは、仕事を担う人と仕事を発注する人を結びつけるシステムのことです。カタカナで表記すると "クラウド" ですが、"cloud（雲）" ではなくて "crowd（群衆）" です。簡単に書くと自社で抱えている人材だけを利用するのではなく、世の中に存在している様々な力（才能・労働力）を利用して、「目的」を達成する仕事のやり方とも表現できると思います。

今回は新サービスのロゴの作成をお願いしましたので、その時に感じたことなどを書いていきます。

もともと知人にデザイナーをやっている人がいるため、これまでのデザイン系の仕事は知人のデザイナーにお願いをしていました。でも、デザイナーさんには作風というものがあって、今回目的としているサービスとは少し雰囲気が異なるんですよね。そこで、周囲の人とは少し異なるセンスを求めてクラウドソーシングのサービスを利用しました。

仕事の発注はとても簡単です。想定している利用場面・顧客層・サービス内容などを箇条書きで提示しただけです。今回は私の知人では手に入らないセンスを求めていたため、色や形など具体的な要望はあえて書きませんでしたが、もし既存のロゴなどがあって、それを今風に変更したいという案件であれば、その目的に応じて対応してもらえると思います。期間は3週間で設定したのですが、実際には2週間くらいで十分な品質を持った作品が提案され、最終的にはその中から作品を採用しました。当初の目的であった "周囲の人とは異なるセンス" を得ることができ、価格・品質の両方で満足する結果が得られました。

さて、今回の結果だけ見れば満足度は非常に高いのですが、これからも利用し続けるかというとちょっと考えてしまう点もあります。

今回私が利用したサービスは明示しませんが、日本でクラウドソーシングサービスを提供している会社に、クラウドワークスとランサーズという企業があります。この二社の利用規約で気になった点を挙げてみましょう。

第5条 本サービスの内容
15. 会員又は過去に会員であった者は、会員又は過去に会員であった者と、本サービスを利用せずに、直接に業務委託契約を締結すること及びその勧誘をすることを行ってはならないものとします。但し、弊社が事前に承諾した場合はこの限りではありません。

第21条 　規約違反への対処及び違約金等
5. 利用者は、利用者が第５条第１５項又は第１２条第６項に違反した場合、違約金として、当該取引の報酬額に対するシステム利用料相当額か金１００万円のいずれか大きい方の金額（当該取引の報酬額に対するシステム利用料相当額の算定が不可能な場合は、金１００万円）を弊社に支払うものとします。

〜クラウドワークス利用規約【クラウドワークス】〜（2013/09/01時点の情報）

第24条 本サイトの取引に関する禁止事項
1. 弊社は、全てのユーザが法令に則って安全且つ快適に仕事の取引を行って頂くために、ユーザに対し、以下に関連する行為を禁止します。ユーザが以下に該当する行為を行った場合、弊社は、その故意・過失であるかにかかわらず違反行為とみなすことができるものとします。
(12) 本サイトを介さずに行う直接取引やそれを勧誘する行為、又は、勧誘に応じる行為。（本サービスで取引開始をした会員と再度取引する場合を含む）

2. 会員が第24条第1項第12号に違反し、本サービスを介さずに直接取引（直接取引を誘引した場合、または直接取引の誘因に応じた場合を含む）をした場合には、会員は前項に定める損害賠償金とは別に、違約金として、当該行為がなければ支払われていたと推定される第10条で定める弊社手数料の2倍に相当する金額（その額が100万円に満たない場合は100万円）を支払うものとします。

〜利用規約 | クラウドソーシング「ランサーズ」〜（2013/09/01時点の情報）

簡単に書くと、「過去に1度でも取引をしたことがある相手と直接取引すると、最低でも100万円もらいます」ということです。なんじゃこりゃ。

クラウドソーシングサービスの登録者の中には、多くのフリーランスの人がいます。この人たちと接触する機会は、個別のクラウドソーシングサービスのシステム内だけでなく、様々な機会があります。ところが、利用規約の文面だけから受け取るならば、このような取引も禁止事項に該当してしまいます。これは将来の活動に対して、大きな制約をかけてしまうことになります。「最終取引から1年以内」など、合理的な期間が設定されているなら話は変わってくると思いますが、現状のままでは大変危険な規約です。

今回は発注側として利用しましたが、普段は作る側の立場ですので、そちらの視点から見ると権利関係でも揉める要素があります。

第14条 　本取引の成果物等に関する知的財産権及びその利用
1. 本サービスを通じてメンバーがクライアントに対して納品した成果物に関する著作権等の知的財産権は、本取引の業務が完了するまでの間はメンバーに帰属するものとし、本取引の業務が完了した段階でクライアントに移転・帰属するものとします。
　本取引の中において別途取決めがある場合は、同取決めを優先します。

〜クラウドワークス利用規約【クラウドワークス】〜（2013/09/01時点の情報）

第14条　タスク方式における会員間の取引
タスク方式の場合、クライアントがランサーの行った作業の承諾をし、支払確定を送信した時点で、承諾したランサー間との契約が成立します。この場合の契約は、当該クライアントとランサー間で特別な合意がない限り、クライアントが選択した成果物の著作権等すべての譲渡可能な権利の譲渡契約とします。

〜利用規約 | クラウドソーシング「ランサーズ」〜（2013/09/01時点の情報）

どちらのサービスも個別に契約すればよいだけですが、著作権関係はよく揉める部分ですので注意が必要です。

私が関わっている仕事でも、発注者に対してすべての著作権を譲渡するという仕事は少なくなってきています。これは、製作者や開発者が権利を保有している著作物だけを使って、（現実的な予算と期間で）最終成果物を作ることが困難になっているという事情もあります。

例えば、システム開発案件の場合、ほとんどのシステムでオープンソースのプログラムを利用しています。当然、これらのプログラムは開発者が権利を保有しているものではありません。デザイン案件の場合にも、フリー素材を使う機会が多くなっています。これらも製作者が権利を保有しているものではありません。これだけでなく、開発・制作側が権利を保有しているプログラムや素材を、他の案件に流用するということはよくあります。「南国の写真を使いたいから」という理由で、案件ごとに南の島までカメラ持って撮影に行くことは現実的に難しいですよね？（一部雑誌などでは、たった1枚の写真のために行っているようですが。）


今回は利用規約の面からクラウドソーシングサービスにダメ出しをしてみましたが、クラウドソーシングは個人的に非常に期待しているサービスなんですよね。会社に行かなくてもお金を稼ぐ手段があるというのは、仕事を受ける側にとって、とてもありがたいことです。発注側の視点で見ても、自社や周囲には無かった才能と出会う機会を得られるという点において、単に労働力を得るという以外に大きなメリットがあります。ただ、現状ではそれらの仕組みが持続的に回っているとは感じられません。

次回は、「こんな仕組みがあったらいいな」という点について書きたいと思います。

Suica利用履歴販売から見る個人情報保護の話

社会

6/27に産経新聞の「経済」で報じられていたのですが、読売新聞の「社会」でも取り上げられましたので、この件について書きたいと思います。

http://sankei.jp.msn.com/economy/news/130627/biz13062716110018-n1.htm
http://www.yomiuri.co.jp/national/news/20130718-OYT1T00726.htm

「個人情報」に関する認識の埋まらない溝

佐賀県武雄市図書館の運営をCCC（カルチュア・コンビニエンス・クラブ株式会社）に委託するという件で、武雄市の樋渡市長と高木浩光氏が論争を繰り広げたことがありました。ここでの論争でも感じたことですが、「個人情報」という用語に関する認識の違いが、議論が噛み合わない理由の一つであると思います。

個人情報保護に関する法律（個人情報保護法）では、「個人情報」を次のように定義しています。

(1) 生存する個人に関する情報
(2) 当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの
(3) 他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるもの

この定義はかなりユルユルだと個人的には考えているのですが、一方でこの定義に合致しないものは「個人情報ではない」と考えている人たちがいるのも事実です。武雄市図書館の論争にしても、「個人情報保護法の定義に合致しないものは「個人情報」ではない」と主張をする樋渡氏と、「個人を特定することができる可能性があるものは「個人情報」である」と主張する高木氏の議論が噛み合わないのは、その実例を見ているようです。

今回のSuica取引履歴の外部販売に関して、JR東日本は次のようにコメントしています。

「名前や住所を匿名化しており、個人が特定される恐れがない」

でもね。名前や住所を匿名化しただけで、個人が特定されないと本気で考えてる？そもそも「個人が特定される」という事象をどのように考えてる？名前や住所が判明しなければ、それは個人を特定したことにならないと考えてる？

確かに1件の履歴だけで個人を特定することはできませんが、それが一年分とかになると、高確率で「特定の個人を識別すること」ができますよね。もしくは、改札前に設置されたビデオカメラの情報や、Suica対応店舗での決済情報などと併せると、高確率で「特定の個人を識別すること」ができますよね。これは個人情報保護法の3番目の条件に合致することになりますよね。

ビッグデータというキーワードで、大量の情報を分析する技術が急速に発展しています。それは、目的の情報に対して容易にアクセスすることができる環境が整備されつつあり、「他の情報との照合」を「容易」にするための技術が実現していることを意味しているのです。技術的に実現可能なことと、社会的に実現可能なことは異なります。この点に関しては、大学病院の倫理委員会のように、「技術的には可能なんだけど、社会的には受け入れられないから止めとこうね」という判断ができる体制を早急に整備しないといけないと思います。

リアルマネーと電子マネーの違い

少し話を変えて、リアルマネー（お札や硬貨）と電子マネー（Suicaなど）との違いを考えてみます。
お金に求められる機能は、次のようなものがあると思います。

1. 価値交換ができること
2. 通貨の最小単位で利用することができること
3. 匿名性があること

「価値交換ができること」というのは、そのマネーを使って同等の価値のものと交換できるということです。お金はもちろんのこと、電子マネーも電車に乗れたり買い物ができたりしますので、お金としての機能を持っていると言えます。「通貨の最小単位で利用できること」というのは、そのマネーを使って任意の価値と交換できるということです。例えばビールとしか交換できないビール券や、お釣りがもらえないギフト券などは、この条件を満たしていません。その点、電子マネーは通貨の最小単位である1円単位で利用することができるため、この条件を満たしていると言えます。

そして3番目の「匿名性があること」とは、そのお金を誰が使ったか追跡できないことです。この点に関して、電子マネーはその仕組み上実現することが非常に困難です。特にSuica系のカードは、利用残高をセンター側で管理する仕組みになっています。（Edyは違ったような記憶があるのですが、自信が無いのでフォローいただけるとありがたいです。）そのため、Suicaを使うということは、センター側で利用履歴が把握されることを意味しているのです。クレジットカードに近い感覚です。自分のプライバシーを厳重に守りたい人は、自衛するという意識を持つことも大切です。

電子マネーの利用履歴は銀行口座の取引履歴と同じ

電子マネーがお金と同等の機能を提供していく戦略であるのであれば、その利用履歴は銀行口座の取引履歴と同等に保護される必要があると思います。

もし、大手都市銀行が、

「マーケティングに利用するため、名前や住所を匿名化して取引明細を公開します」

とか言ったら大問題に発展しますよね。金融庁などの監督官庁からもストップがかかると思うのです。電子マネーの利用履歴というのは、それくらいの意識を以って取扱わなければならない情報なのです。そうであるにもかかわらず、JR東日本は日立製作所に取引履歴の情報を、利用者の許諾を得ることなく渡しました。営業機密として取り扱われているでしょうが、金融機関で取り扱っているレベルでの機密情報とはなっていないでしょう。

この取扱っている情報に対する意識の足りなさが、JR東日本の根本的な問題だと思うのです。

みずほ銀行ATM休止に思うこと

IT 社会

みずほ銀行とみずほコーポレート銀行が7/1に合併します。これに伴って6/29(土) 午前0時から7/1(月) 午前8時まで、ATMを含めた全てのオンラインサービスが止まっています。
そして、このサービス休止に伴って困っている人たちが続出しているというニュースも出ていました。

みずほ銀行ATM停止で阿鼻叫喚 「油断した」「所持金200円しかない」 : J-CASTニュース

私もみずほ銀行の口座を持っていますが、メイン口座として利用していませんので、それほど意識していませんでした。それでも、「週末にサービスが停止する」という情報は知っていました。ちなみに、私の妻はみずほ銀行をメインバンクにしていますが、サービスが停止することを知らなかったようです。特に困っている様子もありませんでしたけど。

今回は、このサービス休止騒動で考えたことを3つほど書きます。

1. 多くの人がATMのシステムを信頼している

職業柄なのか、私はATMなどのシステムを、特に可用性の点で信用していません。可用性というのは、「サービス提供時間帯に問題なくサービスを受けられるかどうか」ということです。つまり、ATMに行ったんだけど、機械が故障していたとか、停電していたとか、回線が切れていたとか、お金が詰まっていたとか、紙幣が入っていなかったとか、ATMに車が突っ込んだとか、酔っ払いが機械を抱えて寝ていたとかのように、意図していないことが原因で使えない事態がどれだけ発生しないかということです。「銀行が倒産してた」というのも、この中に入るかもしれません。

その点、今回のサービス休止で "所持金200円" になってしまった人は、銀行のシステムをとても信頼しているんだと思います。だって、信頼していなかったら常に現金を家に置いておきますよね。ATMに行けば必ずお金を引き出すことができると考えているからこそ、所持金200円という状況になるわけで、それはATMのシステムをものすごく信頼しているということを意味しています。

個人的には、銀行に預けたお金が無くならなければOKかな、と考えています。これって信用しているのか、信用していないのか・・・。
どちらにしても銀行のシステムに対する期待値は、それほど高くありません。

2. 影響範囲の大きい情報を全ての人に周知するのはとても難しい

今回のサービス休止の案内は、テレビCMなどでも大量に流していたようです。でも、私はそのCMを見たことはありません。何故ならテレビを見ないから。

少し前ならほとんどの人がテレビを見ていたので、全時間帯でCMを流せば、1度くらいは対象の情報に触れることができました。でも、最近ではテレビを見ない人が増加しています。だからといって、ネットの広告に必ず目を通しているかというとそういうこともなく、多くの場合は視界の端っこで流れていってしまいます。

このような世の中で、影響範囲の大きい情報を多くの人に周知することが、とても難しくなっていっているように感じます。「どうしてATMが止まることを知らなかったの？」と聞いてみたところ、

・「いっぱいCMが流れていたらしいよ」 → 「テレビ見てない」
・「みずほ銀行のATMにポスター張ってあったでしょ？」 → 「コンビニATMしか使ってないから見ていない」
・「ATMの画面にお知らせとか出てなかった？」 → 「記憶にない」
・「みずほのWEBページにも大きく出てたらしいけど」 → 「ネットバンク使わないのに、アクセスしないでしょ」

とのこと。う〜ん。。。

今回はATMのサービス休止でしたけど、世の中への影響が大きい情報を多くの人に伝えるのって、どうすればいいんだろうな。
やっぱり個別に郵送連絡しかないのかな？

3. みずほ銀行の本当の勝負は2015年のシステム更改の時

みずほ銀行のシステムが脆弱なのは、2002年4月の第一勧業銀行・富士銀行・日本興業銀行の合併の時の不手際に原因があると思います。
3つの銀行のシステムを統合する際、どこが主導権を取るか争った結果、継ぎはぎだらけのシステムが出来上がりました。そして合併のギリギリまで政治争いを行っていたため、システム統合のための十分な時間を確保することができず、大規模障害を引き起こすことになってしまったのです。

その後もみずほ銀行のシステムは刷新されることなく、2011年3月にも再び大規模障害を起こしています。そして現在もそのシステムは動き続けていて、そのシステムが刷新されるのは2015年の予定です。それまでは、でっかい地雷が埋め込まれたシステムを、ずっと使い続けなくてはならないのです。この地雷を踏んだがために、これまでに2人の頭取が辞任に追い込まれています。とりあえず、現頭取はシステム刷新を進めていますので、仮に7/1(月)にトラブルが起こったとしても、頭取辞任まで発展することは無いと思いますけど。

個人的な印象ですが、みずほ銀行のシステムは、大量の処理集中に弱いように感じます。
7/1(月)は週明けで月初でボーナスや給料を引き出そうとする人が殺到する可能性が高いです。利用者の方々も自分の身を守りたいのであれば、緊急ではない現金の引き出しは午後にするのが賢明だと思いますよ。

    • -

2013/07/19追記

7/1(月)は問題なく乗り越えられたようで何よりです。
みずほ銀行発足時のドタバタは、下記の書籍で知ることができますので参考までに。

システム障害はなぜ起きたか~みずほの教訓

システム障害はなぜ起きたか~みずほの教訓

家族計画について

社会

「女性手帳」が話題になっています。うっかり触れると炎上するんじゃないかというレベルで盛り上がってます。
「少子化」と「女性」という2つのキーワードが密接に結びついている点が、世の中から反発を受ける理由の一つであるように感じます。女性手帳の現物を見ていないのでコメントは控えますが、今回は一般論としての家族計画に関する教育機会について書いていきます。


私は子どもの頃にまともな性教育を受けていません。教わったのは「精子と卵子が出会うと子どもができます」という点だけ。片田舎の小学生は「精子と卵子が "どうやったら" 出会うのか」を知りませんでした。いや、知ってた小学生もいたと思いますけど、私だけが知らなかったとは思えないので、そういう子どもも一定数はいったんじゃないかな。両親もこの手の話題は避けていたので、学校で教わらないと知る機会を得ることはできませんでした。もちろん、結婚・妊娠・出産というイベントの生物的な意味だけでなく、社会的な意味についても知ることはありませんでした。

とはいえ、中学生や高校生になってくると、非正規ルートでこのような情報に触れる機会が出てきます。ところが、非正規ルートで入手した情報から伝わってくるのは、「どのようにしたら性行為をしても妊娠しないか」という点です。今でこそ結婚前の妊娠が増えてきましたが、私たちが20代の頃はまだまだ受け入れられているとは言えない世の中でしたので、避妊方法に関する情報はたくさんあったような印象があります。

望まない妊娠を避けるための情報が入手できるというのは、それはそれで大事なことなのですが、「性行為をすると当然のように妊娠する」という意識が知らない間に植え付けられていました。（これが間違いだと知るのは、ずいぶん後になってからです。）以前、松本隆博さんの講演を聞く機会があったのですが、同様の考え方を持った人は多いという話を聞いたことがあります。

さて、結婚して子どもを意識するようになると、「子どもが生まれるのは想像以上に難しい」ということを身をもって知らされるわけです。男女双方の体のリズム（女性のほうが圧倒的にコントロールが難しいという事実）もありますし、そこから受精して着床して妊娠して出産するというのは、本当にものすごい偶然が重なった結果なんですよね。その途中で不幸な結果になると、数カ月とか1年単位で計画がズレていく上に、精神的な負担もとても大きい。そして、このような事例は決して稀なことではなく、当たり前のように発生していることなのです。


私たちの世代の性教育は、望まない妊娠を避ける方法に偏っていたように感じます。それが少子化に直結していると主張するわけではありません。しかし、子どもを望んだ時に、正確な知識や情報が圧倒的に不足していたことを知らされました。これは男性・女性に関わらずです。「女性手帳」がどのような結論になるかはわかりませんが、望む人が正確な情報を入手できるような施策が行われるという点においては、それはそれで大切なことだと思うのです。

JINSオンラインショップへの不正アクセスの件

IT

メガネ通販のJINSオンラインショップへの不正アクセスで、クレジットカード情報を含む個人情報が流出しました。内部では進行形の話ですが、最終報告書が公開されたので、この件について触れてみたいと思います。この記事では、下記の報告書の内容に基づいて書いていきます。

不正アクセス（JINSオンラインショップ）に関する調査結果（最終報告）

まず事件について時系列でまとめます。

日時 アクション
3/6(水) 不正プログラムを仕掛けられる（※事後調査で発覚）
3/14(木) 19:58頃 サイトに異常を発見
3/14(木) 22:50頃 不正アクセスの痕跡を発見
3/14(木) 23:06頃 サイト停止
3/15(金) 不正アクセスに関するお知らせ（第一報）を掲載
3/17(日) 不正アクセスに関するお知らせ（第二報）を掲載
3/18(月) 情報漏えい事故調査委員会設置
4/9(火) 中間報告を掲載
4/22(月) 不正アクセスに対する被害届提出
5/1(水) 最終報告を掲載


今回の事件の第一報で「クレジットカード番号が漏洩した可能性がある」という情報がありましたので、システム側でクレジットカード番号を保存していたのかという記事も流れていましたが、実際にはクレジットカード番号を保存するような機能は作りこまれておらず、不正アクセスをした犯人が仕掛けたプログラムによって、クレジットカード番号を抜き取られていたようです。利用者側から見ると、ATMのカード挿入口にスキミング装置を取り付けられたような感じですかね。

運営側の悪かった点

明確に運営側（JINSおよびシステム保守会社）が悪かった点は主に下記の2点だと思います。

1. セキュリティホールが存在するソフトウェアを使い続けたこと
2. システムが改竄されたことに気付かなかったこと

不正アクセスの主要な要因は、セキュリティホールが存在するソフトウェアを使い続けたことで、システムの内容が改竄された点にあります。おそらく、今回の不正アクセスの直接的な原因になったソフトウェア以外にも、セキュリティホールが存在しているソフトウェアを使っていた部分があるんじゃないかと思います。このあたりも含めて全面的な見直しが必要だと思いますし、これだけの事件になってしまったので見直されることを期待します。若干気になった点としては、システム保守会社に責任をふっかぶせるような印象を受ける報告書だったことです。上場企業でもあるし、大人の事情があるのかもしれませんが、「システムの保守はベンダに任せるぜ！！オレたちはそれを管理するだけだぜ！！」という気持ちを持ち続けていると、また同様の事件が起きてしまうのではないかと不安になります。「今後はシステムの保守・運用にも主体的に関わっていきます。」くらいの表明があっても良かったんじゃないかなと思います。

3/6(水)にシステムを改竄されて3/14(木)に異変に気付いているわけですけど、何がきっかけで異常を発見したのかという点は興味深いです。一般に公開されることは無いでしょうが、そのきっかけが無かったら今も改竄されたままだったり、被害に気が付かないまま新バージョンのプログラムで上書きしていた可能性もあったわけです。後者の場合には、不正アクセスの痕跡も含めて消される可能性がありますから、異常を発見できたというのは "運が良かった" のかもしれません。

運営側の良かった点

事故が発生しているので "良かった" という表現は語弊があるかもしれませんが・・・。

1. サイトに異常を発見してから、システムを停止するまでの時間が短かったこと
2. 事故発生後の対応が良い意味でシステム的に行われたこと

報告書の内容を信用するならば、19:58にサイトに異常を発見してから、およそ3時間でシステムを停止しています。この時間を長いと見るか短いと見るかは意見が分かれると思いますが、報告書に記載されている保守体制から推測すると、19:58に異常を発見した後に保守担当会社に調査を依頼しているはずです。その結果、サイトが改竄されていることが22:50に判明し、23:06にサイトを停止しています。JINSは調査結果が判明してから約16分でサイト停止（停止作業も保守担当会社が行っているはず）しています。独立した複数組織が関わっていることを考慮すると、この決断時間は早いのではないでしょうか。

異常を発見したのがECサイトの責任者であったとの記載もありますが、組織の中でのサイト停止に関する権限委譲が十分行われていたとも考えられます。事後だから言えることですが、19:58にサイトの異常を発見した段階で停止することができれば、もっと良かったと思います。


また事故発生後の対応は良い意味でシステム的に行われています。これは主に下記の点についてです。

(1) サイト改竄が判明した後のシステム停止
(2) 不正アクセスがあった事実の公表
(3) 第三者の専門調査機関を入れた調査体制の整備
(4) 調査の進捗状況の公表

こちらも推測になりますが、事故が発生した際の対応方法が、事前にマニュアル化されていたのではないかと考えられます。

今回の事件から得られる教訓

JINSと同様にECサイトを運営している企業は、今回の事件からどのような教訓を得れば良いでしょうか。

1. セキュリティホールがあるソフトウェアを利用しない

今回の事件の直接的な原因ですからね。

私が今まで関わった案件に限定して言えば、中小規模の企業が運営しているサービスよりも、自社に技術専門チームを持たない大規模企業や官公庁のほうが、セキュリティホールがあるソフトウェアを利用していることが多い印象です。セキュリティホールが修正されたバージョンを適用すると、想定していない影響が出ることがあります。そして、大企業や官公庁のほうが、このような影響が出ることを避ける傾向が強いのです。既に攻撃コードが公開されているような場合であっても、バージョンアップの決裁を取るための社内会議が2週間後ということを経験したこともあります。これを考えると、JINSの判断はとても素早かったと思います。

2. 不正アクセスが発生した際のマニュアルを整備する

今回の不正アクセスの異常に気付いたのが19:58です。おそらく営業時間外の緊急対応ですよね。
今回は平日に異常に気付きましたが、これが土日だったらどうなっていたでしょうか？またサイトを停止するために担当役員の決裁が必要な体制だったら、どうなっていたでしょうか？「週明けに上司が出社してから聞いてみよう」という意識だと、被害規模はどんどん大きくなっていきますからね。このあたりの対応品質が、担当者によってバラつきがあるというのは良くありません。

不正アクセスというのは、クレジットカード情報の漏えいだけに限らず様々な種類があります。これらの攻撃を100%防止することは事実上不可能です。そのため、不正アクセスが発生した際の対応方法を事前にマニュアル化して関係者に周知徹底するというのは、とても大切なことなのです。

3. クレジットカードを取扱うメリットとデメリットを良く考える

JINSが再発防止策として、以下の2点を挙げています。

(1) 画面遷移型のクレジットカード情報非保持サービスを採用
(2) PCI DSSへの準拠

この方法には若干疑問を感じています。

クレジットカード情報非保持サービスとは、クレジットカード決済を専門として取り扱っている会社のサービスにアクセスさせ、そこで利用者がクレジットカード番号を入力し、その後自社ECシステムで決済完了情報を取得するという方法です。確かにこの方法だと、クレジットカード番号が自社ECシステムを経由することはありませんので、今回と同じ方法での攻撃を受けることはありません。しかし、外部からシステムを改竄できるとすると、決裁サービスへアクセスさせるためのURLとして、偽のURLを仕込むことができてしまいます。「意味が無い」というわけではありませんが、クレジットカード番号が自社システムを経由しないから安心という考えでいると、同様の問題が発生してしまう可能性があります。

PCI DSSの準拠についても、セキュリティレベルを上げるという意味においては良いと思います。しかし、インターネット経由での販売をメインとして扱っているわけではないサービスの場合、コストをかけてPCI DSS準拠のシステムを構築するメリットが本当にあるのでしょうか？いっそのこと、自社サイトは集客とプロモーションに注力して、販売はAmazonや楽天に任せるという方法もあります。現実的には、今回の対応も保険対応になっているでしょうから、金銭的な影響は軽微なのかもしれませんけどね。

4. 自社が担当している部分以外にも主体的に関わっていく

やっぱり、コレが大きいんじゃないかと思います。

「システムの部分は全部任せているから、常にシステムを完全な状態を保て！！」というスタンスでは、やっぱりうまくいかないと思います。システムに存在しているリスクとか費用とか時間とか、これらに関して責任を持って決定するのはサービス提供会社です。全ての運用を自社で行う必要はありませんが、システム部分に対しても主体的に関わっていく必要があると思います。

開発・保守担当会社にしても、自社で開発した部分だけ対応すれば良いというわけにはいきません。現在のWEBシステムは、第三者が開発したプログラムが大部分も占めています。第三者が開発したプログラムや、サーバやネットワーク等のインフラについても、最新の情報を収集する体制と対応能力が求められていると思います。


この手の問題って、「○○をすれば安心」という解は存在しないので、いろいろ大変だと思いますけど頑張ってくださいね。（私も頑張りますので。）