« 2006年3月19日 - 2006年3月25日 | トップページ | 2006年4月2日 - 2006年4月8日 »

悪のプログラマ―――もっと冴えたやりかた

 「悪のプログラマ」[参照]で、優れたプログラマが本気で犯罪に手を染めるなら、痕すら残さないゾと書いた。さらに、デバッグとしてのソースレビューだけでなく、犯罪防止のためにコード検閲が必要だとも言った。

 ところが、この容疑者はそれほど優れたプログラマではなかったようだ。以下、「NTTデータ元社員が取引記録を不正利用しカード偽造の疑い」[参照]より引用。

 NTTデータは、2005年10月と2006年2月に発生した偽造ローンカードによる不正キャッシング被害に関連して、同社から仙台銀行のATMでカードを利用した際の取引記録の一部が不正に持ち出されていた可能性があることを発表した。

 容疑者の元社員は、システムの運用にあたっていた人物。彼のやりかたのどこがマズかったかを指摘し、「もっと」冴えたやりかたを提案してみる…が、それだけだと教唆になっちゃうので、防止策も。

媒体(ここでは紙)が噛んでいる

 誘拐でも横領でも、足がつくのは着服するところ。身代金受渡であれ、現金化するところであれ、たいていの犯罪はここで発覚する。元社員はせっかく暗証番号を含む三点セットを手に入れたにもかかわらず、わざわざ印刷→持ち出したらしい。

 オッサンは、なんでもとりあえず紙に出す習性があるが、この人もそのようだ。犯行の直接的な発覚は不正利用のアラートだろうが、紙に出すことで動かぬ証拠を残してしまったに違いない。

⇒冴えたやりかた1:犯行の媒体を減らす

 媒体は使わない。出力はデータセンタで行われたものと思われるが、まさにそこに監視の目が輝いている。ミッション・インポシブルは大げさだけど、メディア(紙、FD、CD-ROM、DAT、USBメモリ、… 最近じゃケータイも)に吐くところはセキュリティレベルも高いぜ。だから、冴えたやりかたは「媒体に残さない」。

 具体的にどうするかまで書いたらそれこそ教唆なのでカンベン。あなたがプログラマなら、この時点で複数のルートを思いつくはず。

現金化を考慮していないクラッキング

 不正に持ち出された三点セットを元に偽造カードを作成→不正キャッシングをしたらしい。情報を盗むところをクリアできても、盗んだ情報を使うところでヘタを打ったら意味が無い。ほとんどの犯罪はここでバレる。盗む前に「どうやってその情報を現金化するか?」の課題をクリアしておかないため、誰でも思いつくキャッシングで尻尾をつかまれる。

⇒冴えたやりかた2:クラッキングだけでは不十分

 現金化から逆算して、盗る情報を絞る。アラートの旗を立てないようにするならば、キャッシュではなく□□□□として売っ払うという手もある。どちらも足がつかないように、恒常的に受渡できる「仕組み」を作りこんで、その仕組みそのものを売るというのもアリ。

古典的な着服方法

 情報を盗むだけなら普通のプログラマでもできる。痕を消すことを思いつくのは、魔がさした普通のプログラマ。で、現金化までを想定してプログラムまで書けるのが、悪のプログラマだ。

 この元社員は、ログ出力プログラムを改ざんするぐらいの知恵は回ったらしいが、そいつを足がつかないように現金化するところまで頭が回らなかったらしい。

⇒冴えたやりかた3:現金化を見越した作りこみ

 クラッキングだけでなく、現金化するところ「も」作りこむ。警察の捜査とは、犯罪を実行する後ろの「人」を探す諸々の行動。だが、犯罪を実行するのが「人」ではなくプログラムだったら? もちろん実行するコンピュータの持ち主という足がかりはあるものの、ホレ、人を隠すには人の中、というじゃぁないか。プログラムを隠すにはプログラムの中、というやつ。

 ズバリ書けないのがもどかしいが、ふたつみっつ思いつくだろう。嫁さんに振ったら「捕まる人はキャッシュを求めるからいけないんじゃない? "マネー"にしちゃえば?」とトンデモナイことを言った。やりおる!

 また、そのプログラムを書いたなら、そいつを動かすタイミング、消すタイミングもセットで考えるだろう。ニッパチは取引が少ないのが常識なので不正使用が目立ちやすいだろう。さらに、制度更改やシステム入替で混乱しがちなのが盆暮れとゴールデンウィーク。プログラムの実施時期はおのずと決まってくるだろう。

 ちなみに、本件の犯行時期は2005年10月と2006年2月。このへんを一切考えていなかったことがよく分かる。プログラマとしては並以上だったかもしれないが、犯罪者としてはあまり優秀ではなかったのかもしれない。

 冴えたやりかたは、たったひとつではない。優れたプログラマであればあるほど、いくつでも思いつくだろう。まさに alternative solution を幾つも用意できるのが、優れたプログラマの定義なのだから。

 「優れた」プログラマでなくても、「悪の」プログラマにはなれる。こうした悪知恵は自分で思いつくだけじゃなく、公開されたネタからさらにブラッシュアップできる。わたしだけじゃなく、元記事を読んだ方は、きっとこうつぶやいたはず。

わたしだったら、もっと巧くやるのに
―――――――――――――――――――――――――――――――――――

 さて、後半ではこうした犯罪を防ぐ方法を書く。

 運用業務の監督は各自で頑張るとして、根幹はあれだ、モラリティと一言で片付けられてしまう奴。ここでは、優れたプログラマが本気で悪いことを考えた場合、企業はどうやって抑止できるかを考える。

自らのパワーに気づいていない魔法使い

 ほとんどのプログラマはとてつもない権力を持っているにもかかわらず、気づいていない人が多い。「権力」は語弊があるが、うまい言葉が見つからない。「使い方しだいで善にも悪にもなるが、世の中に大きな影響を与えるパワー」という意味。

 このパワー、悪い方に使うなら、好きなだけ盗れる。呑む席でよくネタにするが、この人が本気でやったら絶対足がつかないだろうなーというプログラマは結構いる。

 「めちゃくちゃ忙しいけれど、やりがいは皆無、かつ、給料安くてやっとれん」ため息まじりの愚痴にうなづきながら、この人のモラルへの代価は会社で賄っていねぇよなーとも思ったり。

 優れたプログラマは、魔法使い並のパワーを持っているにもかかわらず、警官並のモラリティを要求される。しかしながら給料は… どこぞの若造が「いや、技術を通じて自己実現ができるからモチベーションが云々」と言いそうだが、桃源郷はヨソでやっとくれ。

 いま「まだ」平和に見えるのは、大部分のプログラマが自らのパワーに気づいてないから。リアルとネットがこれだけ近づいていて、機密にもアタッチできる立場ならば、そのうち気づく人がもっと増えるはず。そのとき彼・彼女を止められるのは、モチベーション云々ではなく、モラルの一言に尽きる。そして、その対価は支払われていない(し、これからも支払われないだろう)。

魔法使いは「魔法使い」使いが監視し、「魔法使い」使いは、「『魔法使い』使い」使いが監視して…

 ジョージ・オーウェルのミニチュア版を謳うつもりは無いが、相互監視を前提とした開発・運用の業務はアリかと…で、監視する人を監視する人を監視して…(n次の入れ子)、が成り立つ。社員のモラル向上へはビタ一文も対価を支払うつもりがない経営者は、nに好きなだけ大きな値を入れればいい。

 もう少し気の利いた経営者なら、「魔法使い」たちを一同を会し傾向と対策を好きなだけ論じさせるだろう。穴(security hole)を指摘する人もいれば、ドアを普請する方法(softether)を解説してくれる人も出てくるに違いない。んで、魔法使いたちに対策を練ってもらう(もちろん充分な見返りを保証する)。

相互監視のためのペアプログラミング

 ペアプロの利点として代表的なのは、以下の4つだろう。


  • スケジュールが短縮される
  • 若手プログラマの育成につながる
  • 1人で開発するよりもストレスに強い
  • コードの共同共有により品質が向上する

 ここに5つ目の利点が加わる。即ち、「相互監視による犯罪の抑止」だ。「相互監視」なんて、冷水を浴びせる言い方で恐縮だが、この利点はアナウンスしなくても充分な牽制となる。また、コードの共同共有はヘタなコードを潜り込ませないようにする抑止効果がある。

 あと、品質管理担当が「コード検閲」をする…なんてアイディアもあるが、現実的ではないだろう。要求仕様を満たしているかひいひい言っているのに、検閲なんて… いやいやそれでも、ブラフとしても効果があるかもしれない。

まとめ


  • ダメなやりかたは「媒体を残す(今回は紙)」「古典的な現金化では足がつく」
  • 冴えたやりかたは、「犯行の媒体を減らす」「現金化を考慮したハッキング」
  • 対策は、「魔法使いには魔法使いで」「牽制としてのペアプロ」

 で、結論。優れたプログラマが本気で取り組んだなら、痕は残らない。wizardry は魔法使いというだけでなく、「優れた技術」という意味もある。淡々とハックするのを見てると、「充分に発達した科学は魔法と区別がつかない」というセリフを思い出す。

 最後に。「悪のプログラマ」がどこかにいるかのような書き方をしたが、そんな奴はいねぇ。プログラムを悪用する人がいるだけ。魔法そのものは善でも悪でもなく、ただその使い手によるのと同じ。

 次のターゲットは、ケータイだな
 魔法使いさんおしずかに。

| | コメント (4) | トラックバック (0)

プログラマになれなかったわたし

 今は昔、ひとりの駆け出しプログラマがいた。

 その頃はCOBOLばかりで、しかも保守ばかりだった。そこで、独学で身に付けたCをやらせてもらえる仕事を奪ってきては書いた。スクラッチプロジェクトを見つける嗅覚だけは抜群だった。たいていは人手が足りず、新人でも歓迎されたからだ。

 そこには優れた先達がいた。「スーパープログラマ」と呼ばれていた。

 なぜ「スーパー」なんて修飾子がついたかというと、速いプログラムを早く書いたから。もちろん、「速い」とは少ないメモリ・小さいプログラムのことを指し、「早く」とは実装が早いこと。実際、彼らが書いたプログラムはサクサク動き、バグは簡単に見つけられた。

 教えを請うと、先達たちは、おしなべてこういった。

 最初に学ぶべきは、コンピュータサイエンス。特にアルゴリズムとデータ構造だ。実践的なコーディングテクニックよりも、まず基礎だ。これはコードを書きながらではなく、文献から学んで欲しい。

 次はソフトウェア工学だ。設計・開発手法や、テスト技法を身に付けて欲しい。これは学校でやっていなくてもOJTを通じて「まねぶ」ことができる。

 ところが目先のコードを書き上げるのに手一杯で、先達たちが貸してくれた「参考書」を読む時間なんて無かった。…いや、ウソはいけない。「書き上げるのに手一杯」はウソだ。

 確かにコーディングに追いまくられていたのは事実だが、その傍らで続々と出てくる「新技術」 …Java、UML、J2EE、XMLを知るのにも必死だった。まだ手垢のついていない「オブジェクト指向」というコトバそのものが伝家の宝刀として扱われ、それが何であるかを知る前からそいつを振り回していた(まさにキ○ガイに刃物)。

 新しい記法、新しい技法、新しい用語、新しい言語を齧るたびに、成長した気になった。「速習」「すぐ使える」「かんたん」で始まる本ばかりで、入門から一歩も先へ進んでいなかった。

 それでもコードは書けた。必要なことを順番にコードにするのがプログラマだと信じていた。そして「必要なこと」とは、仕様書に書いてあることか、指示されたことの二つしかない、と思っていた。

 仕様書なんてアテにならず、ソースコードこそが仕様であると確信していた。その正しさを証明するために印刷したコードを振り回しながら、相手に読んで理解することを強要していた。だから、コードが読めない人(能力だけでなく、時間的に読めない人も含む)は、仕様が理解できない人だと決め付けていた。

 COBOL、C、Java と言語の種類が増えるに反比例して、コードを書いて欲しいという依頼は減っていった。いっぽう、SEやPMの立場の仕事が大半を占めるようになった。そして、『プログラマ』という肩書が外された。そのとき上司は「年齢的に大変だろう、30超えてるし」と告げた。

 認めたくなかったが、本当の意味でプログラマにはなれないことが分かった。使える言語は増えたが、どれも極めていない。とりあえず言われたことを書くだけの「コーダー」だった。

 「書いてないことは書けません」が決めゼリフだった。(設計書に)記述されてないことは、(プログラムに)書けません、という意味だ。あの頃は勝利宣言のつもりだったが、振り返ると、コーダー宣言だったに違いない。つまり自分へのトドメ。あるいはプログラマとしての死刑宣告書へのサインだったのかも。

 「コンピュータがどうやって動くか」の本質なんて変わってやしない。それに気づかないまま新しいモノばかり追い求めてきた結果がこれだ。SEとしても、コンサルタントとしても、PMとしても、偉そうなことをぬけぬけと言い放っているが、一皮むけばこんなもの。

 今は過去の遺産でしのいでいる。上っ面だけかもしれないが、量だけはこなしたので、もうしばらくいけるだろう。その間に別の「新技術」を習得して「知ってる君」になって吹聴する…をループ。大丈夫、昔のネタを別の名前に替えただけのものを「新技術」と売り出しても咎められないみたいだから、巧み立ち回ればグルを名乗ることもできるかも。

――――――――――――――――――――――――――――――――――――――

 以上、「浮ついた「ギーク」への説教(※老害注意)」を読んだ、あるプログラマ「だった」人の告白を書いてみた。

 え? 表題に「プログラマになれなかった『わたし』」とあるって? 気にしない気にしない。だって、『あなた』と書いたら問題でしょ?

| | コメント (0) | トラックバック (1)

« 2006年3月19日 - 2006年3月25日 | トップページ | 2006年4月2日 - 2006年4月8日 »