元ネタはこれ
岡田斗司夫さん「プロフィールを改ざんされた」とmixi退会
http://www.itmedia.co.jp/news/articles/0904/02/news094.html
岡田さんが退会直前に更新したmixi日記によると、「mixiのプロフィールが何物かに無断で改ざんされる事態が続き、頻繁にパスワードを変えても改ざんされた」という。
岡田さんは事務局に知らせ、対応を求めたが、「対処や理由説明もなく、突っ込んだ質問をしたら返信そのものがなくなった。『原因は分からない』『調べようがない』という答えしかなかった」ため、「mixi運営事務局そのものが信頼できなくなった」としている。
んと…多分。岡田さんというかたの側からしてみれば、少なくとも「プロフィールの改ざんがあった」のは、おそらくは「間違いのない真実」で(これが「ぢつは勘違い」だと以降の話が続かないのでその可能性は意図的にオミットします)。
mixi側からしてみれば…おそらく。
・システム的な不具合があればほかのユーザからも同様の事例があがってくるはず(で、多分上がってないんじゃなかろうかとおいちゃんは予想
・取得しているログの範囲では不正なアクセスの痕跡はなかった
などの理由から「因はユーザ側にあるんじゃないかなぁ」という判定をしているのではなかろうかと思うです。いやまぁ「そのチェックその他がどこまでコレクトなものなのか」ってのはおいといて。
まぁこの手の問題は、双方の言い分の想像がつくだけに、色々と悩ましいなぁと思う…って感想程度でしか、正直ないのですが。
このニュースそのものに対しては。
ただ「業者としての」自分としては、やはり「こういった問題が発生した時」への想定をいくつか考えるわけです。
で…以前から思っていたですが。
実際問題。じゃぁ自分が組んだシステムで「厄介なクラック」が起きた場合。apacheログとか、多少なり程度組み込んだ程度のアプリケーションlogとか程度ではぶっちゃけ「追い切れないので再現待ち」ってことも多いですよ。
んでもって。
ちと、MWのほうで。こゆoptionをconfigに組み込もうかと思ってるです。
all_log_request
all_log_response
概ねそのまんまの内容。mvcやってるとこゆ時便利よｗ
all_log_responseは…「動画をプログラム経由ではき出している時」なんかにかなり問題が起きそうな気もするんだけど…まぁそこは追々考えましょう。一番雑には、動画データを出力するmodelインスタンスに「model_ins->all_log_response_off();」とかってやってもいいし。これはこれでいくつか憂慮すべき問題も出るんだけど。
もちろん色々な観点はあると思うのですが。
つまりは観点の一つとして「HDDとかのコストを支払ってでも有る程度万全な体勢をとっておきたい」という想定が、あって然るべきだと思うわけです。
最近HDDとみに安いしねぇｗ
…そか。ってことは。
all_log_sql
ってのも欲しいんだ。
多分いくつか想像できる反論があるんだけど。Web側で実装すると「依頼してから結果到達まで」が計れるから。DBサーバだとどうしても「依頼到達から結果送出まで」なので。確率は低いけれども、その差違が問題になる可能性も否定は出来ないわけだし。
DBを分散化した場合のメリットもいくつか想像はつくし。
後は。
memory_get_usageって関数があるので、これをロギングすることは以前から想定してたので(limit超えたら警告ってのもあるしね)。
ちとその辺色々考えてみよう。
ってなわけで、memo。
