http://www.nikkansports.com/ns/soccer/p-sc-tp0-050729-0011.html
最後方の客席でも、日産スタジアムの最前列（ピッチまで最短３０メートル）よりも近い。
うはは。同じ設計事務所とは思えない仕業だなあ（爆笑）。でも早く行ってみたいよー。
関東圏のスタジアムはほぼ行ったけど、柏スタジアムを超える臨場感が味わえるのだろうか？はっきりいって市原臨海は作りが最悪なだけに、期待でかいなあ＼(^O^)／
このスタジアム、だれかがふと思い立って設計してるときにサポ有志の声を聞こう、と思ってくれたのがものすごく転機だったかも。サポーターがキャンペーンとかしたのが奏功したのだけど。
http://www.itmedia.co.jp/enterprise/articles/0507/27/news020.html
いろいろと考えさせられる一件だけど、
カカクコムの場合、こうした副作用リスクの中で一番心を痛めたのが、技術系メディアによる「詳細を公開しないのはけしからん」という論調だったという。
「公開することによるメリットもあるが、公表した場合のリスクが読めないことから言わないようにしていたが……」（遠藤氏）、結果として社員への心理的なダメージは相当大きかったという。原因や詳細の公表に関して同氏は「何らかの社会的なコンセンサスがあればよかったかもしれない」とも述べた。
けっこう読んでいたのねいろいろと、とかいう脊髄反射はさておき（笑）。
もとからセキュリティに関心を持って追いかけている人たちというのは、メディアも含めてこのあたりの議論を何度か経てきているので、感覚として直後に「SQLインジェクション」とかいうキーワードだけでもあれば良かったのに、と思えるわけですよね。しかし、ここで正直に告白されているように、遠藤さんには少なくともそういう感覚が無かったわけですね。ニッチなセキュリティ業界での議論が外にちゃんと届いていなかったから、とも言えるし、そもそもセキュリティに気を配るべき立場なのに、そういう情報をおさえてなかったのねorz、とも言える。しかしまあ、これは永遠の課題なんだろうけど、今のところは知ってる人、気づいちゃった人がいろんな場面で発言、情報公開し続けるしかないのかな、という気がします。事件があるとキーワードだけは流布するようになるけど、じゃあ具体的にSQLインジェクションされないようにプログラムを作るにはどうしたらいいのか？っていう、必要な知識が現場にわたっているのか？というと疑問もあるんだよなあ。そしてさらに疑問なのが、対策することによって予算がかかるんだけど、その予算を出す立場の人に、そうしたものの脅威がどれだけ伝わっているのか、ということなんだよねー。
なんといっても現場がいくらノウハウを持っていたとしても、そのノウハウを使うことにお金が出てこなければやれないわけですよね。
しかし、「だから仕方ないよ」といって逃げているだけでは、いざ事が起きたときには現場に責任をひっかぶされて（また現場の技術者とかってマジメだから、無理筋の責任追及でもまじめに「言われてみればそうかも知れないなあ」なんて受け取っちゃったりして）、いろんな意味で潰されてしまう。そうならないために、リスクヘッジとして、知識や理論武装して事前に「セキュリティの提案」を行っておくべきなんでしょうね。「提案」には1人月追加（テスト含む）かかりますが、どうしましょうか？提案を蹴られた場合には、SQLインジェクション耐性は知りませんが、ってなことを最初に言って、受け入れていただけるのならおっけーだけど、拒否されたら責任は逃げられるような契約にしとかないと、とか思います。
まあもちろん、受け入れられたときにそれに応えられるだけのノウハウが無いと、こういうこともあり得ないんですけどねえ（笑）。
逆に、セキュリティは任せた、とかって放り出されたときも困りますよね（苦笑）。そういうときは出てきた見積もりを見てダメ出しとかされがちですが、放り投げのときほど相手の感覚やら文化やら背景やら予算やらを考慮して、それでもこれだけはやりましょう、というのを提案して詰めていくのが、有る意味コンサルテーションとしての醍醐味だったりするわけで。
いずれにしても危機感を多少なりとも持ってる相手の方が、セキュリティ入れた提案は進めやすいですよね。やはりそうじゃないときに、どうやって振り向かせるか、「情報漏洩しますよ？いいんですか？」と開き直れるかなどがポイントになるのかなあ？
もちろんセキュリティってのは、最大の的は内部の人だったりするんですが、実は外敵の侵入にきっちりしっかり対応していれば内部の人、例えばここで示唆されているベテランプログラマ、マスターであろうともその目を逃れることは難しい、とは思いますね。
例えば、ここで示されているようにシステム自体が正当な記録を出力できないように仕込まれてしまったとしても、周囲がハニーネットであれば異常を捕捉できるかも知れないし、別なサーバー、別な管理体系のもとに記録を残すことができるわけですからねえ*1。
そこまでの仕掛けをごまかすためには、ネットワーク管理者とかも抱き込む必要がありますよね＞暗黒プログラマ。
ということは逆に言えば、暗黒プログラマと暗黒管理者が組んだら理論上最強になるわけですが（爆笑）、そんなサービスの中核人物が二人とも暗黒＝会社に何らかの強い不満を抱いている状況なんてーのは、その状況を招いてしまった会社の自業自得であると思えますね（苦笑）。そんな状況になる前に、少なくともプログラマかネットワーク管理者、どちらかの現場の社員くらいは最低限正当に扱うべきでしょうねえ。
っていうか現在、現場では逆に、システム管理者とかの方が疑われたりするケースも多かったりするみたいですしね。コンピュータを自在に操ってわけのわかんないこと、魔法じみたことをやってる人々に対して漠然と不安感を持っている経営者多いみたいだし。そういう面でも理不尽な扱いになってしまってたりするわけですが、あらぬ疑いをかけられる管理者としてはまさしくやってられねーという感じですよね。薄い給料に文句も言わず働いてるのにこれかよ、みたいな。
もっと言えば管理者にしろプログラマにしろ、暗黒面に堕ちていないことを論理立てて証明（これも微妙ですけどね）できるように心がけていないとならないのか、という論点もあったりして。セキュリティがそういう猜疑に満ちた幸せな組織を招きつつあるということですかねえ（苦笑）。
*1:もっともこの最初の異常検知、というところが難しかったりするのですが
http://trombik.mine.nu/~cherry/w/?p=310
ちうお題をいただいたので脊髄反射してみようっとヽ(´ー`)ノ。
SQLインジェクションというキーワードが無くとも、確かに後始末っぷりとかを見れば原因は想像はできますけどね。ただ、原因を見ればわかる人にとって必要だ、ということではなく、そもそもそれ以外の人にプロモーションするために必要だと思いますねえ。キーワードってのは結局そういうもんですよね。
あちきがそういうものでも有れば良かったのに、と思っているのは、もし後続の類似の事件が無ければ、得体の知れない者に得体の知れないやり方でやられてた、という印象しか一般の人たちには残らないわけですからねえ。そうなると提案の場、もしくはその提案を吟味する場で一段話が通じにくくなると思うんですよね。
そういう場にキーワードを植え付けるくらいのことすらもできなかったら、この事件はそれこそ脅しあげの材料にこそこそっと業界な人たちが使うだけ、という、とってもつまらない事件の再利用になるんじゃないのかなあ。ってとりあえずここだけ脊髄反射しておこう（笑）。
キーワードについてもう少しｗ。
http://www.itmedia.co.jp/enterprise/articles/0410/30/news001.html
門林先生のおっしゃることは、そのままではなくてもう少し読み解く必要があると思います。ベンダー側がマーケティングのために作り出すキーワードのいかがわしさというのが、そもそも混乱を招いているのだ、という側面は否めないすが、それは例えばIPSと言ったりIDPと言ったり、はたまた発展型IDSみたいな言い方をしたりすることを指すのではないかなあ。しかし、SQLインジェクションは他の言い方という混乱させる要素はありませんよね。
しかし、マーケティングの圧力によって、「SQLインジェクション」という言葉が濫用されてしまうおそれは残りますね。これは極端な例ですが「SSL-VPN製品です。SQLインジェクションも（ある意味）防げますよ」みたいな言い方をすると、門林先生の言うもう一つの弊害を起こすおそれはあります。しかし、これまで語られてきたものでは説明しきれないものなので、誤用さえされなければこの言葉を使ってリスクを説明するしかないんじゃないですかねえ？
つまり、ファイアウォールだけを入れておけばおっけーだと思っている経営陣に、それだけでは足りませんよ、ってことをどう説明するのか、ということですね。SQLインジェクション、クロスサイトスクリプティング、というキーワード無しで語ろうとすると、例えば「Webアプリケーションに対して正規のアクセスを行うふりをして、データベース操作を行ってしまう攻撃方法や、ある人のふりをしてログインしたりする攻撃手法があり、それはファイアウォールでは防げないんですよ」という、ちょっとぬるい言い方をして、「へーそうなんだー。でもどうしてファイアウォールでは防げないんですか？」と反問されて、そこで「それは正規の通信ポート使って通信してるからで、ファイアウォールは通信を通信ポートでしかチェックしてない（というのはウソだけど（笑））ので防げないんです」などと苦しい展開をしたり、あるいは慣れない営業が「ちょっと戻って技術陣に確認してきます（汗）」ということになるよりもはるかに話が早い、と思うんですがどうでしょうか？そういう場で非専門家である顧客をさらに混乱させないためにもキーワードは必要だし、だからこそ今こそいろいろなメディアでこのキーワードの意味するところを解説しまくって定着させる必要がある、と思いますけどねえ。
ついでにこのお題にもヽ(´ー`)ノ
リスクヘッジてのはある意味保身ですよね。けれど、おっしゃられているように組織の中で少々の保身＝リスクヘッジをしたところで、結局潰される、ということも事実としてはあるでしょう。しかし、そこでそのまま潰されてもいいのでしょうかね？
そういうのに対してソリューションを考えると、例えば「潰される前に辞めてやる」というのが一つ。まあそれが一番楽そうですね。結局個人に責任取れ、と言っても、じゃあ辞めてやらぁ、としか言いようがない場合も多いし。
しかし、いろいろな事件の動向やらを見ていると、単に辞めてもらう、というだけでなく、それを懲戒解雇として退職金とかも出さないとか。あるいはもっと酷いのは損害賠償請求までしてくるとか。もちろん無理難題として500円×460万人分ってことはありえないですが、個人として負えるだけのものを負わせるとかってことは、これは社会的にアピールする意味でも今後はあり得るような気がします。
そうなると裁判ですよね。
裁判で勝つためには、自分のための証拠が必要ですし、その証拠となりそうな材料をそろえておく、というのがリスクヘッジではないかと思います。
もっと言えばそれは保身のためだけではなくて、実は作業の確認や引き継ぎに普通につかえる情報・記録だったり、あるいは会社自身を守るためにも使える材料となるものだったりするはずですね。さらに、それでヒューマンエラーを防ぐものでもあるし、監査して作業のやり方をチェックするためのものでもあると思います。
あと重要なのは、そういう記録を残すことによって、お互いによこしまなことを企てない、という心理的抑止効果も期待できると思いますね。
自分のリスクヘッジとしてやることではありますが、結局仕事や会社のためでもあるわけですよね。そういう記録をちゃんとした形で残しておく、というのは。
しかし、記録を残そう、しかも証拠として力を持つような形で、となると、一手間二手間よけいにかかることが多いのも事実です。そうなると業務効率化や成果主義などの組織内圧力が強い情勢のもとでは、会社のためになるのに公認ではその一手間をかけられない、ということも考えられますよね。
でも、現在のように個人情報の取り扱いには敏感な時期（一過性かも（苦笑））であれば、そういう手間を増やしてでもリスクヘッジ追加の提案が通りやすいと思うんですよね。
