仮想環境ではもう触ってはいるんだけど、そろそろWindows8に乗り換えるかどうかは結構迷いどころ。僕はWindowsは開発機兼テスト機なので割と慎重にならざるを得ません。
また同時に今もっとも悩んでいるのは「32bit版のままで行くか、あるいは64bit版に乗り換えるか」です。
もちろん利用できるメモリ量などを考えれば64bit版の方が有利なのですが、実は開発で用いているVisual Studioには32bit版しか無かったのです。と言っても64bitOSでもWOW64環境で動くことは保証されていますし、32bitOSと同じく64bitOS上のVisual Studioでも32bit/64bitアプリ共に問題無くコンパイル可能です。
ただそれでもやはり「ユーザーが最も利用している、これから利用するであろう環境で」開発することは重要と考えています。
そこで「現時点で32bitOSと64bitOSそれぞれのシェアを調べてみよう」と思い立ちました。
まあインフラ周りの仕事をしていてよくご存じの方には今更の話なんですが、近年家庭用のNAS(外付けHDDでもですが)も安く出回って一般ユーザーにも広まっており、何かの参考になるかなあと思ったので書いておきますね。
以前まともにバックアップしていなくて開発したソフトのコードを全損しかけた(笑)経験から、家庭用外付けハードディスクを幾つか渡り歩いた後、メーカー限らずあまりによく壊れるので(理由は熱暴走とか突如のHDD破壊とか様々です)、試しにRAID対応のNASを買ってみました。結構前のことで、2009年春頃のことです。
買ったのはバッファローのLS-Q2.0LS/R5という機種で、これを選んだ理由はあまり覚えていないのですが、 「値段手頃」で「その前に壊れたのがIOデータ製だったから」とかそんな程度の理由だったと思います。
いわゆるPCの定期バックアップと言うよりは普段使わないデータの保存先が主な目的で、一時期MacのTime Machineバックアップにも使用していましたがその後純正Time Capsuleを買ったのでその目的では使わなくなりました。また開発コードやコンテンツなども最新版をコピーしていましたが、同時にsubversionも使用していますので、基本的にはこれまでのデータの退避先ですね。
という状態で3年ほど何事も無く過ぎていたのですが、基本的に先日家に帰るとNASが停止していて、すぐには気付いていなかったのですがアラートメールが届いていました。
非常に分かりにくいメールでしたが(なので一般ユーザーだと何が起こったのか、分からないんじゃないかなあ。。)、どうやらRAIDを構成するディスクにエラーが発生し縮退運転に入り、また縮退運転時には自動停止する設定にしていたのでNASがシャットダウンされていたようです。
RAIDで運用している訳ですからエラーの出ているHDDを普通に交換すればいいだけなんですが、アラートメールだけでは詳しい状況が分からなかったので試しに起動し直してみると、意外にも「壊れたHDDは2台」だったことが前面のアクセスランプから判明しました。ここで多少血の気が引いていくのを感じたのを覚えています(笑)
一般的にRAIDと言われるとよく知られているのはRAID5では無いでしょうか。こちらにRAIDの種類については詳しい説明がありますが、RAID5というのは「パリティと呼ばれる、他の残りデータと組み合わせると欠損データを回復できる仕組みを用いた冗長化」が主な特徴になっています。このパリティは常にHDD1台分のデータが必要とされるのでRAID5を構成している1台のHDDが故障してもこれを交換すれば自動的にデータ復旧が行われて回復可能です。
しかしHDD2台が同時に破損するとデータ復旧は不可能です。
http://www.data-sos.com/raid/raid09.html より引用
しかし僕はすっかり忘れていたのですが、RAID10で運用していたのでした。
RAID10は、RAID1 + RAID0が命名の語源で、まず構成されるHDDは二つのミラーセットに分けられます。書き込みデータはRAID0と同様にストライピング(ミラーリングの単位で分散配置される)とともにRAID1のようにミラーリングセット間でミラーリングされます。パリティは無いのでRAID5より信頼性は劣るとされますが、同じミラーリングセット内で無い限り、二台のHDDが故障してもデータは保証されます。
http://www.data-sos.com/raid/raid015.html より引用
僕の場合はまさしく、「たまたま」この故障した二台のHDDは二つ存在したミラーリングセットそれぞれの一台ずつで、幸いにもHDD2台を交換することで正常にリビルドが行われ、元に戻すことが出来ました。良かった良かった･･･
これは先に示したサイトでも詳細に説明されていますが、そう単純なことではありません。ここに記載した事例は「幸い良い方向に倒れた一つの事例」に過ぎません。
RAIDなどのバックアップ方法は「求める目的」と「許容できる障害範囲」(と場合によっては「パフォーマンス」「容量」も)によって選ばれるべきです。でも、そこの見極めが難しいんですよねえ。
先に書いたとおりですが、企業内利用ならともかく、個人利用だと目的や要件が利用しているうちに変わってしまうことは多いでしょう。するとRAIDも含めてバックアップ方針はそれに応じて変更することを常に考えた方がいいでしょう。
一般的には、RAID対応のNASを買う以上はほとんどの場合そのバックアップ内容に「信頼性」を求める場合がほとんどかと思います。しかし例えばRAID5にしていても、常にディスク状態をチェックして交換用ディスクを準備してすぐに交換できなければ(RAID5では1台が故障中にもう1台故障すればデータは全損します)RAIDを組んでいた意味がありません。また昨年の計画停電時には停電でRAIDのコントローラーやHDDがダメージを受けた例が多発したそうです。そうした場合で無くとも、極端な場合落雷や過電流などでHDDが全損する可能性もゼロでは無いはずです。
実は僕の場合、何故HDDが同時に2台故障したのだろうかと疑問だったのですが、よくよく調べてみると、実は1年以上前に故障したHDDの1台からエラーが発生したというアラートメールが届いていたのを見過ごしていました。ただアクセスランプは正常だったので恐らく自動的にエラーセクターは修復されていたのでしょう。しかしそもそも調子は悪かったはずで今回エラーになった際に同時に巻き込まれた？などと推測しています。しかし最初のエラーの際にディスクチェックや交換などを行っていればもう少し状況は変わったかも知れません。しかし個人での運用なんて「その程度」のものなのですよね。
逆に言えばRAIDなどハードウェアに頼り切るよりも、実は運用こそが重要と言えるかも知れません。
今回の件からは、例えばRAID対応NASよりは、例えば安く買えるRAID対応していないNASを2台並べて、またはNASに外付けHDDを増設して定期的に一方向バックアップでも十分かなあと思い始めています。
メディアバックアップも意外に馬鹿にはできません。最近は4層120Gに対応した書き込み型Blu-rayディスク(BDXL)もありますので、本当に重要なデータなら選択的にこれらを活用してもいいでしょう。
またプライバシーや情報漏洩上は問題も指摘されますが、1TBなどの非常に大きなデータで無い限りは、クラウドのバックアップサービスを選択しても良いでしょう。これは例えば自宅が火事や災害によって被害を受けることを想定した場合には非常に有効です。
上記は「無くなっては困るがもう頻繁には更新されない重要なデータ」には有効な手段でしょう。
実は今僕が使っているLS-Q2.0LS/R5に限らず、バッファローのNAS/外付けHDD用の交換HDDって、とっても高いんですよ！
数が出る製品でも無いので、アマゾンでも1台=2万円ほどしており、つまり今回は2台で約4万円も交換にかかってしまいました。。。
そもそもここまでコストをかけてHDD交換するか、別のNASに買い換えるか悩んだんですが、別のNASにした場合データ移行時に現在のNASで仮にもう1台HDDが故障した場合はもう全損なので、安全を取ってHDD交換/リビルドを選択してしまいました。つまり体よく「メーカー・ロックオン」されてしまった訳ですね。一応「出荷時に専用検査とエイジングテスト実施」とは謳っているんですが、あまりに高いでは無いですか、そもそもこのNASは45000円で買ったものなんですけども。なのでせめてあと3年は使えてくれないと困ります。。
そもそものRAID(Redundant Arrays of Inexpensive Disks)という名称の由来に反してませんかねぇ。。
幸い最近は専用で無くとも市販の安価なHDDで組めるRAID機も多く出回っていますので、皆様におかれては「交換ディスクは幾らで買えるか」もちゃんと確認してRAID対応NAS/外付けHDDを選ばれるようにオススメします(^.^)
NHN JapanのLINEアプリが大人気だ。
全世界のユーザー数が4000万人を超え、国内でも1800万人のユーザーを突破したという。 今でも月に500万人が登録し続けており、年内にも1億ユーザーを目指す、という。
驚くべきはその成長率であり、LINEは2011年6月に公開されてまだ1年しか経っていない。しかし全くの新規アプリ・サービスでそれだけの期間に4000万人が登録したコミュニティというのは他に例は無いだろう。
OGC2012のNHN Japan自身の講演によれば、 会員2000万人突破にかかった期間は256日であり、これはTwitterの1035日・Facebookの1152日に比べても驚異的と言えるだろう。
無論こうした爆発的な人気の原因には、そもそものコミュニケーションツールとしての使いやすさ・取っつきやすさや、無料であること、TVCMなどのマーケティングなども大きな要因であろう。
しかし僕はそこには、これまでどのサービスも乗り越えてこなかった大きなポイントがあると思う。
それは「ネットワーク構築のショートカット」である。
随分間が空いてしまいましたが、やはりまとめておくことにします。
前回までにドコモへ問い合わせた内容はこちら。
世間的にもこの問題は下火になっており僕もそれで構わないとも思いますが、質疑応答の過程で幾つか意義のある論点もあり得たかと思いますのでそれを中心にまとめます。
何が事実だったのか、あるいはドコモの主張だったのか
IMEI(International Mobile Equipment Identity)は個々の端末固有に紐付けられるユニークなIDで「携帯キャリア(電話会社)により端末の識別を行う」際に利用されるIDです。通話時やデータ通信時には常に送出されており携帯キャリアは把握することが出来ます、例えば盗難端末が携帯網に接続される場合にそれを拒否して使えなくする、などの使われ方をします。
IMEIは端末の恐らく電池パックの裏などにも印字されていますしまた箱にも書かれていることも多いです。またそもそも皆さんが携帯端末を契約した際にはキャリアでどの契約者にどのIMEIの携帯を売ったかは当然記録されており(つまり契約者と紐付いている)例えば契約書には電話番号と同時にIMEIの記載されているはずです。(但し中古品を買ったなどの場合はこの限りではありません)
このような目的ですので携帯キャリアがIMEIを把握したり利用することは想定内の利用方法です。しかし今回恐らくは初めてIMEIがキャリア以外のC/Pへ通知されることになった、ことがこれまでの使われ方とは異なる大きな問題なのです。これはIMEIの定義やこれまでの通信事業者の論理からすれば世界的にもかなり驚くべき事例かと思います。簡単に言うと何とも安直にIMEIを「目的外利用」することになったものです。
つまりIMEIというキャリアにとっては契約者に紐付くIDがC/Pへ通知されることでC/Pではこれを用いてユーザーをユニークに見分けることが出来るようになります。また悪意を持って見れば、複数のC/Pがキャリアに内緒でデータを持ち寄ってデータの突き合わせをし、より完全で詳細な個人情報を組み立て上げ売買したりシェアし合うかも知れません。IMEIは決して変動するIDではありませんのでほぼ未来永劫に渡って一度紐付けられたあなたの個人情報は業者から削除されたり無効になることは無く、例えばどのサイトへも少しアクセスしただけでもあなたが一体何者で他のサイト含めてこれまでどんなコンテンツを購入したり閲覧したか、などが丸わかりになる可能性も出てきます。再度繰り返しますが、これが未来永劫続きます。
これが所謂「固定ID」の危険性であり、「名寄せ」と呼ばれる個人情報収集手法です。
まとめると、本来携帯キャリアの管理下にしておくべきIMEIが外部で利用されてしまうこと、上記で述べたように固定IDによる名寄せリスク(プライバシー)が懸念される問題と言えます。
これは微妙です。
但しメディアプレイヤーのみの送信、それもライセンス取得時のみと言うことからは、常に全てのC/Pで行えることでも無いでしょう。これはライセンスサーバーをきちんと立てて運用するにはそれなりに運用コストもかかり、ただ個人情報を取得するだけの目的では簡単には行えないと考えられるからです。保証は出来ませんしもちろんそうした運用を行った上で悪意を持って名寄せをするC/Pがいない保証もありませんが、例えば当初懸念されていたように「ブラウザが無条件でIMEIを送信する」事態に比べればリスクはよほど低いとは言えるでしょう。
また現在普通に行われているように、サイトで簡単にやはり同じように契約者を固定IDで特定できるiモードIDが取得できてしまうことに比べればよほど問題は小さいです。
但しこうしたリスクは少ないながら付きまとっていることはしっかりと把握しておきましょう。
質疑応答からもドコモは「固定IDのリスクについては承知している」と繰り返していました。しかしながらにも関わらずこのように安易にIMEI(固定ID)を利用してしまうのは、もちろんC/Pへの配慮という大きな問題はあったと思いますが、同時にIMEIなど固定IDに変わるソリューションをきちんとC/Pに提供できなかった「プラットフォーマーとしての責務の欠如」に大変懸念を感じます。
これは別エントリーにて後日もっと詳しく述べられるといいなあとも思うのですが、簡単に言えばドコモがプラットフォーマーとして利用者の期待に応えられず、C/Pの要望にただ流されているという懸念すべき状況であるとも言えるでしょう。
これはアップルが同様にプラットフォーマーとしてどのような施策をしているかと比較してみればよくわかるでしょう。
現在の大きな潮流の変化(スマフォへの移行や世間のプライバシー問題の関心の変化)にドコモ自身が付いていけないことを露呈した、あるいは白旗を揚げている事例では無いかと思います。
今後一点注意しなければならないと思うのは、今回の事例が前例となって、「端末固定IDはライセンス取得・コンテンツ保護のためには必須」という理由が「錦の旗」化してしまわないか、という懸念です。
当然アップルやアマゾンの例を見て分かるように、端末に紐付いた固定IDは別にコンテンツ・ライセンスのための必須条件ではありません。
しかし少なくとも日本のデジコン業界では「ライセンスは端末に紐付いたIDでしか守れない」神話が根付いてしまっているようです。そしてまたユーザーも簡単にそれを(その先のリスクを理解していないので)受け入れてしまっている事実があります。
ライセンス取得と端末固定IDは全く別なのだ、ということはぜひとも広く理解して欲しいし、実のところこうしたことはデジコン業界がユーザーに問題を押し付けて自分たちが楽を出来るからに他ならない、と言う点は理解しておきたいと思います。
—
ドコモからの回答では「きちんと利用者に固定IDの危険性を啓蒙していきたい」との段がありました。またこの問題がどのように変貌していくかは実際に運用が始まらないとわからない点もあります。
当面の問題は少ないにせよ、今後とも興味を持って注目していきたいし皆さんにもお願いしたいところです。
この記事はauのEZWebがそろそろ終了しそうな件の続編です。
当該記事では「EZブラウザとPCサイトビューアーのIPアドレス帯域が統一される」ことから場合によってはEZWebの課金システムや一部認証が脆弱性に晒され得るのではないかと危惧したのだが、もしかすると本当に現在それが起きていた(いる)かも知れない。
F001（PCサイトビューアー）※一部伏せ字
あれ？REMOTE_ADDRが111.87.241.##？
これ、2011年秋冬モデル以降の一部機種のEZブラウザ/PCSVのIPアドレス帯域じゃないですね。
従来のPCサイトビューアーのIPアドレス帯域でもありません。
EZWebとPCサイトビューアーのIPアドレス帯域が具体的にどんなアドレスになるかは上記の通り既に公表されているのだが、どうやら現在PCサイトビューアーからアクセスすると全く別のアドレスになっているようだ。つまり以前からのアナウンスにも関わらずEZWebとPCサイトビューアーのIPアドレス帯域は統一されておらず別のものになっているようだ。これは何を意味するのか。
auの2011年秋冬モデルである「F001」のHTTPヘッダが従来機と比べて大きく変更になっているようです
通常のEZwebブラウザとPCサイトビューアーのIPアドレス帯域が統一された関係で、PCサイトビューア＋JavaScriptを使っての値のねつ造ができないかどうかが気になります。
上記の記事を見ると、本来来るはずのない帯域からアクセスが来ているとのことなのですが、この辺りの問題が解決できてなかったからとかではないでしょうね。。。
恐らくk-tai.orgさんの予想か当たっているのではないだろうか。
これは想像だが、当初はもちろんEZWebとPCサイトビューアーのIPアドレス帯域は統一されたのだろう。しかしPCサイトビューアーでEZWebのHTTPヘッダーのケータイID(個体識別番号、サブスクライバーID)を偽装できる問題が発覚してしまったのでは無いだろうか。
そのため少なくとも一時的にでも問題を回避できるように、PCサイトビューアーのIPアドレス帯域をEZWebとは急遽別にしたのではないか。
以前の記事からも繰り返しになるが、ケータイIDを脆弱ながらもぎりぎり安全に保つには一般に三つの条件がある。
(1) そのアクセスがそのキャリアの携帯網(IPアドレス帯域)からのみであることをサービスプロバイダーが保証すること
(2) 携帯網ではケータイIDが偽装されていないことをキャリアが保証すること
(3) 端末の自由度を低くしてケータイIDの偽装などの可能性をできるだけ低く保つこと
このうち2についてはauでは採用されていない可能性がある。そして今回PCサイトビューアーとIPアドレス帯域を統一することで1でサービスプロバイダー側にてEZWebからだけのアクセスでありHTTPヘッダーのケータイIDをそのまま信じていいのかどうかは微妙になった。後は3の条件のみが頼みの綱となった。
すなわち「PCサイトビューアーからケータイIDを偽装して付加できることがあっては絶対にならない」のだ。もしそうなってしまえばケータイECの信頼性は崩壊する。
しかしながら、それが今回偽装できることが発覚してしまったのでは無いだろうか。
以上はあくまで想像に過ぎない。またとりあえずPCサイトビューアーのIPアドレス帯域が緊急的に変更されているのなら差し迫った危機は回避されている。
そこで以下のような公開質問をauのカスタマーサポートへ行ってみた。
「PCSVのIP帯域とセキュリティについて」 表題についてご質問です。 1. 今秋冬モデルからEZWebとPCSVのIP帯域が統一されるとのアナウンスがありますが http://j.mp/vzi7QB http://j.mp/tG3hDj こちらの記事 http://j.mp/uEniDb によれば実際には記載の無いアドレスからPCSVはアクセスされているようです。 これは事実ですか？事実である場合理由は何ですか。 2. どこかでこれらはアナウンスされていらっしゃいますか。 3. http://j.mp/v4AqrD では「PCSVにてHTTP_X_UP_SUBNOの偽造が可能なのでは」との推測がされています。 私も同様の疑いを持ちますが事実関係はいかがでしょうか。 4. 3が事実であった場合、現在まで告知がされていません。それは何故ですか。脆弱性は隠したいとの意図でしょうか なお本件は公開質問として送付させて頂いております。ご回答に付き適時適切に公開させて頂く場合があります旨ご了承下さい。 以上、お忙しい中大変恐縮ではございますが、ご回答頂けましたら幸いです。どうぞ宜しくお願い致します。
(なお質問がつっけんどうで分かりにくく感じられると思うが、これはauの問い合わせフォームが上限500文字で最低限まで文字数を削る必要があったためだ。せめて1000文字ほどあればもう少し丁寧に書けるのだが…)
結果が帰ってくればまたご報告したいと思う。
以前脆弱性公開ポリシーについてauへ質問した際には、「システムに脆弱性があることについて事実確認されアップデートによって脆弱性が解消できることが判明した場合には必ずWEBサイトで告知を実施した上でアップデート対応を実施する」「セキュリティに関わる問題については悪用される危険性があるため詳細な内容については公表しない。但し該当ユーザーについては個別に周知している」と回答頂いているので、仮に事実であれば問題解消後には必ず公表されるだろうし、また少なくともF001ユーザーやコンテンツプロバイダーには事後報告がされるはずだ。今回の件はその試金石となることだろう。
事実であったとして、F001にはセキュリティアップデートが行われるかも知れない。しかし全ての端末がアップデートをするとも限らない。とすればIP帯域の統一は簡単には戻せないかも知れない。果たしてどのような改修が行われ得るだろうか。
今後その点にも注目しておきたいと思う。
追記(2011/11/23)
Kimuraさんの検証によれば、F001のPCサイトビューアーではJavaScriptでUserAgentおよびX-UP-SUBNOの変更や追加は出来なくなっているとのこと。(以前の機種では出来た)
F001のPCサイトビューアーでsetRequestHeader
こうした仕様はIPアドレス帯域を統一する以上想定内(大前提)の仕様なのだが、にも関わらずIP帯域が分けられていると言うことは、これを回避して変更・追加する方法が存在するということになりますね
追記(2011/11/28)
KDDIから回答が来ましたが、「PCでもPCサイトビューアーでもHTTPヘッダーの書き換えが出来るのは当然のこと」「セキュリティ確保のためEZWebとPCSVのIPアドレス帯域は分離している」のだそうで・・。この自分で整えたちゃぶ台をひっくり返す回答はどうしてくれようか、混乱中です･･･。
因みにEZfactoryのお知らせとIPアドレス帯域に変更がされましたね。何やらこれまでアナウンスしていた「EZWebとPCSVのIPアドレス帯域の統一」が無かったことにされているのですが・・？？
とりあえずこういう質問にしておいた。
以前よりKDDI様では「2011年秋冬モデルよりEZWebとPCSVのIPアドレス帯域は統一する」とアナウンスされていらっしゃいましたが、 下記ご回答とEZfactoryを拝見する限り、これらが無かったことになっているようですね。 今後ともEZWebとPCSVのIPアドレス帯域は恒常的に分離されたままになる、ということでしょうか。 またずっと以前よりアナウンスされていた内容がここに来て突如変更された理由は何でしょうか。私が指摘させて頂いていたように 「当初統一する予定だったが、本来変更できてはいけないX-UP-SUBNOがF001のPCSVでは変更できてしまった脆弱性(または仕様抜け) が発覚したため、予定を変更してIPアドレス帯域を分離することにした」との理由しか思いつかないのですが、いかがでしょうか。 仮にこれが事実であれば全ユーザーが影響を受けるセキュリティ問題であった訳ですから、お立場のある通信事業者としては 隠蔽するのでは無く明白に公表されるべきと思いますが、いかがでしょうか。
追記(2011/11/29)
徳丸浩氏から今回の脆弱性の詳細について公表されました。
KDDIの新GWで「かんたんログイン」なりすましの危険性あり直ちに対策された
端的にはPCSV単独の脆弱性ではなく、PHPなど特定言語との組み合わせの問題ですね。しかし結果として脆弱性として「合成」されてしまう訳で･･･。悩ましいですね。ただ当面は回避されていること、かんたんログイン時のみの問題であることはまだ幸いであるとも言えるでしょう。
追記(2011/12/03)
遅くなりましたが、11/30に上記質問に対してauより返答がありました。
「敢えて」そのまま回答を掲載します。
IPアドレスの帯域は恒常的に分離しておく予定です。 以前よりアナウンスしていた内容を変更した理由は、セキュリティ確保のためです。 セキュリティ確保のために、IPアドレスを分離したことは既に公表しております。 詳細につきましては、セキュリティの観点から回答は差し控えさせていただきます。
とのことです。
この回答への評価についてはまずは皆さんにお任せしますが、後日別途エントリーを上げるかも知れません。