7pay 問題・続メモ

*1

今回のインシデント。
余りにも初歩的な業務フローミス(仕様のミス)であるんだけど、
その後の対応もあり得ないレベルで失策。


まず、「監査部門からセキュリティについては問題なし」と念押しした。
そして「これからに関しては調査中」と繰り返した。
一番あり得ない。


まず、インシデントが起こったとき、まず初めにするべきは影響範囲の調査と、
セキュリティ計画に乗っ取ったインシデント対応。
会見では「計画のけの字」も聞かなかったぜ。


まず、セブン&アイ・ホールディングスほどのユーザー企業なら、
セキュリティ計画を実施してない訳がない。


社長は、敢えてか知らないけど、自社のセキュリティ計画すらガン無視して記者会見した


ガン無視したならまだいい方で、コレほど巨大なIT企業に関わらず、
インシデント発生時の計画がなかった可能性がある。
ホントにあり得ない。


また、社長はセブンペイのシステムについてまるで知らなかった。
そして、セブンペイのシステムを作っているのは、NTTや日本オラクルなど、
著名なIT企業などの、その「協力会社」だという。


セブンペイのシステムを作ったのがSIerゼネコンであることは明らかだ。


勿論、SIerで実装をしているのは偽装請負や、派遣で雇われたプログラマーである。
コレほど単純なミスを、現場のプログラマーが知らなかったわけがない。
現場プログラマーの認識が監査部門に届いていなかったのは明白だ。


正直、この機能を作って、「他のメールアドレス入れたらどうなるんだろう」と考えない訳がない。
SIerゼネコンのどこかで、
この問題は「顧客が求めてるんだから実装するんだよ」になったのだ。


余談だけど、SIerゼネコンは、去年も多重請負構造が原因のセキュリティ事故を起こしてる。
"国税庁 240万件マイナンバー流出事故"
いい加減自社でプログラマー雇え。


コレはSIerと仕事をする全ての会社が抱えるリスク。
間違いなくコレは認識しないといけない


じゃあ、外国のIT企業はどうしてるのかと言うと、
Amazonがセキュリティではないけど、インシデントを起こした事がある。


ある日Amazon Web Service の北米ヴァージニア州にあるデータセンターの重要な機能(S3ストレージ)が全てダウンした。
被害額は想像もつかない。


Amazonはこの原因を調査し、北米データセンターにあるエンジニアが、
間違って、特権ユーザーで、一部のサーバーをシャットダウンするつもりが、
重要なサブシステムまでシャットダウンしてしまった事が原因だとわかった。


Amazonはコマンドを打つ際の規約を改訂し、二度とインシデントが起きないようにした。


ここで重要なのは、インシデント発生から原因特定、復旧まで4時間しかたってないのである。


勿論、Amazonは色んな企業に避難され、エンジニアも始末書を書くはめになったが
AWS現在でも世界で一番儲けてるクラウドサービスである


ここで大事なのは、何故ここまで早い調査が出来たか、である。
勿論、エンジニアが「自分がやりました」と正直に答えたからだ


何故エンジニアが正直に答えられたか、
仕事を首にならないからである。
間違いは間違いなのだから、認めて、正しい仕事をすればいい



これが日本ではそうはいかない
日本のプログラマーはほとんど派遣か偽装請負であり、間違いを報告すると首になるのだ。
残業も増えるしな


セブンペイは原因は現在も調査中で、影響範囲も分からない、という。
実際に作った人が何処の誰だか分かってないのは明らかだ


これは「正直に報告する文化がない」SIerゼネコンの致命的な構造であり、
監査部門も社長に意見を具申できなかった、日本文化の問題だ


Amazonは大避難を受けながら、4時間でインシデントを解決した。
セブン&アイ・ホールディングスは、原因が分からないし、影響範囲も分からないそうだ。


そして、どこを止めればいいか分からないから、システムがはそのまま動き続けるそうだ
どんな日本企業でも、セブンペイになるリスクがある

*1:7pay問題、これとは別の角度から、現場の「技術者」「専門家」の目線から。備忘録として。king-biscuit.hatenadiary.com