クラウド・コンピューティングにおけるセキュリティー関連の情報

自分の備忘録としてもまとめておく。

1. Cloud Security Alliance Guidance

    第二版になって、大分中身が整理されました。セキュリティーの専門家向けです。読み物というよりはリファレンスという位置づけですね。

2.  ENISA Cloud Computing Risk Assessment

    上記のCSAも第二版でクラウドに置く資産の評価から始めようという記述を追加していますが、こちらのガイドはリスク評価中心のアプローチなので、既存のシステムをクラウドに移そうという場合には使えるガイドかもしれません。

3. IBM Cloud Security Guidance IBM Recommendations for the Implementation of Cloud Security

    自社の発行なのであまり悪いことは書けないですが、もう少し絵が欲しいかなという内容。まぁRedPaper扱いなので今後Updateされると思います。

どのガイドも一長一短で、これを読めばバッチリというものが無いのが現状です。特にセキュリティーに詳しくない読者に対してはSaaS/PaaSとIaaSを一緒くたに語るのが無理があると思っている今日この頃です。

Paul Van Dyk Volume Tour 2009@新木場ageha

子連れのプラレールツアーの報告後の連投で恐縮ですが、10/10に新木場agehaで行われたPaul Van DykのGIGに行ってきました。

Paul Van Dykは毎年１回くらいのペースで来日しています。昨年は代官山UNITというやや小さめのクラブでプレイしたのと、FUJI ROCK FESTIVALに出場しています。UNITのGIGには私も行って、音が良かったので満足しました。一昨年は今年と同じagehaで、その前もagehaかな？２年前の時はうちの奥さんも一緒に行ったのを覚えています。もう今は子供が（二人も）いるので、奥さんは一緒に行けないのが残念です。

いつもagehaでプレイすると前座の人が入って、Paul自体はAM2:00頃からのプレイになります。今年もそのつもりで行ったら、スケジュール自体がAM3:00からで、前座のYodaの後ろでジャーマンなスタッフの方がMacBookProやミキサーをセットし始めたものの何度もやりなおして、結局Paulのプレイが始まったのがAM3:30でした。今年はagehaに入るための行列が嫌だったので、23:30くらいにagehaに到着して並ぶことも無くすんなりと入れたのですが、スタミナが持たなかった．．．年も年ですしね。はぁ。

Paulのプレイですが、いつものごとく、一曲一曲をゆっくりかけていくのではなく、曲と曲がマッシュアップされて短時間でめまぐるしく、しかも自然な感じでつながっていきます。他のDJと違って、自分の曲や自分がRemixした曲が多めの感じですかね。また、Paul Van Dykというと”トランス”ということで有名ですが、DJプレイのときはハードな感じのジャーマンテクノ系の曲が多いです。ジャーマンテクノのガッツンガッツンとベースのはっきりした４つ打ちの後にトランス調の曲でアゲるという感じですね。今年は去年と比べてもテクノ調の曲が多く硬い感じのプレイでした。個人的にはもうちょっと甘めの選曲が好きなので、昨年のUNITの時の方が良かったかな。

最新アルバムに入っているHomeという新曲も他の曲にマッシュアップされながら流れて、聞いたことが無いトランス調のミックスがされていました（原曲はアコースティックギターなども入っているロック調の曲）。旋律があまりに美しかったので、ちょっと昇天しかけてしまいました（トランスしかもPVDやFerry Coasten、Alex M.O.R.P.Hが好きな人なら分かると思います）。

今回agehaに行ってビックリしたのは、全くタバコ臭くならなかったこと。完全に分煙化されているんです。他のクラブだと全身ヤニ臭くなって、子供がいる家に帰ったらすぐにシャワーで流していたのですが、今回は全く平気でした。（シャワーには入ったけど）ただ、agehaで残念なのは音響があまり良くないこと。個人的にはただ音量がデカイだけと感じるんですよね。UNITなどの方がメリハリがあるというか出音が割れていなくて好みです。テクノは所謂電子音楽ですが、歪みギター系の爆音と違って、綺麗な音は綺麗に出てくれないと気持ち悪いというか聞き疲れするんですよね。弊店してしまった西麻布のYellowも音響は良かったので、agehaの音響も何とかしてほしい。巨大なお店の作りといい、複数のDJが同時に違う場所でプレイするスタイルといい、スペインのイビサ島風な唯一の東京のクラブなので今後に期待したいです。

なのはなプラレール号

10/12 ３連休最後の日に息子を連れて、このツアーに参加してきました。ツアーを見つけたのもGIZMODE JAPANさんの記事です。

息子はもともとプラレールファンではありませんでした。きかんしゃトーマスの大ファンで最初は海外産の木製レールシリーズという、電動では無いタイプを買い与えていたのですが、だんだんと電動で動くものに興味が出てきたようで、木製レールシリーズはすっかりお払い箱で最近はプラレールトーマスシリーズにはまっています。

今回のツアーは記事にある通り、行きはお座敷列車のお座敷でプラレールを遊び倒し、帰りはSLみなかみ号（D51機関車）で帰ってくるという鉄オタ垂涎ものの企画です。鉄道で遊ぶことと乗ること以外のアクテビティは一切ありません。正直２歳の息子が丸一日鉄道に乗っているだけで飽きないのか疑問があったのですが、鉄道好きだから大丈夫ということで予約しました。

当日は朝９時頃に品川駅に集合し、お座敷列車であるなのはなプラレール号に乗りました。乗っていきなり、プラレール大会の始まりです。どうやらうちの息子のように単に円形のレールで遊んで満足な子供（でっかい子供も？）は少なく、皆さんお座敷列車のテーブル（長さ5m以上ある）一杯にレールを敷き詰めます。うちのように子供のためというよりは自らの趣味で参加しているお父さんも多数いました（笑い）。

プラレールで遊んだ後は、JRのコスチューム（駅長さん仕様かな？白いやつです）を着て記念写真撮影、お弁当とスケジュールが進んでいきます。終着駅である越後湯沢まで結構時間がかるスケジュールだったのですが、乗ってみて理由が判明、この列車ノロノロ運転で、乗降が無いのに駅に停止したりもしばしばでした。まぁプラレールで遊ぶ場所を提供するということでゆっくり走っているんでしょうね。

なぜかプラレールのレールをお片づけしたあとに、プラレール５０周年記念である特急（新幹線ではありません）こだま号の列車セットを頂き、しばらくすると終着駅である越後湯沢に到着しました。

越後湯沢からSLに乗るわけではなく、何とこのなのはな号は、２０分ほどの休憩の後にそのまま元来た線路を戻ります。実は往路で既に復路で乗車するSLと客車を見てしまっています。なんだかこれは頂けない展開ですが、うちの小さい息子にはなんだか分からなかったようで不評は出ませんでした。

帰りは２時間ほどの時間をかけてD51蒸気機関車が引く客車で帰ってきます。息子も私も始めてSLに乗ったので感動でした。特に息子はSLに乗る寸前に寝てしまい、無理やり叩き起こしたのですが、初めて見るSLに寝起きで泣くことも泣く大喜びでした。

日帰りにしてはちょっとお高いツアーでしたが、日ごろママっ子の息子が一日パパと二人で泣くこともなく楽しく旅行できたのはかなりの成果でした。良い思い出が出来たと思います。

家族３人あるいは４人で参加されていた人が多かったので、下の娘が大きくなって出歩けるようになって、同じようなイベントがあれば家族全員で参加したいと思います。

クラウド・コンピューティングのリスク

最近は、仕事関連でクラウド・コンピューティングのセキュリティーについて調査している。クラウド・コンピューティングを導入した、あるいは導入を検討している日本の企業の殆どが導入にあたっての懸念事項にセキュリティーを挙げているようだ。

確かに、データセンターの中でどのような設定がされ、運用されているかがブラックボックスになっているクラウド・コンピューティングのサービスでは利用者が不安を抱くのも仕方が無い。

しかしながら、考えても見るとクラウド・コンピューティングの歴史は浅いが、未だ大規模なセキュリティーに関するインシデントは発生していないのが現実ではないだろうか？（Salesforce.comの顧客リスト漏洩問題があるが、これはデータセンターの問題というよりは社内の顧客情報管理の問題なのであえて除外する）

そこで、もう一度クラウド・コンピューティングのリスクは何か？と考えてみた。最近発生したTwitterやFacebookに対するDoS攻撃の例を考えるとクラウドに対するサイバー・テロ（およびそれによるサービス停止）は、あまり議論されていないリスクだと思う。だが、DoS攻撃は攻撃元からのトラフィックを遮断して被害を少なくすることが可能だし、永遠に攻撃が続くわけではない。そう考えると、実はベンダーロックインの問題が一番リスクなのではないかと思うに至った。

Amazon EC2のようなIaaSの形態であれば、中で動くアプリケーションなどはオンプレミスのものをそのまま使うことが出来るし、データ形式なども通常のサーバーで稼動するものと同じである。しかしながら、PaaS, SaaSではどうだろうか？Salesforce.comなどではCSVでデータを吐き出す機能を持っているが、大量の顧客データをCSVで吐き出して、別のクラウドにインポートして使えるように再構成するのは大変である。PaaS, SaaSではデータ形式などが共通化されていないので、一旦あるクラウド・サービスに乗ってしまったら最後、そのベンダーと心中することを決めなければならない。

このことは、２つのリスクをもたらす。１つはベンダーが倒産したり、サービスをやめてしまった場合に、そのサービスを利用する業務が続行不能になる可能性があること。もう１つは、技術の陳腐化、競争力の低下の可能性である。今でこそクラウドのサービスは時代の最先端というイメージがあるが、それはクラウドのベンダーが最優先に大量の投資をインフラやサービスに投入しているからである。さて、あなたが心中を決めたクラウドのベンダーは永遠に時代の最先端を走れるという保証があるだろうか？ハードウェアの交換やプラットフォームを構成するソフトウェアのアップデートなどをクラウドのベンダーはあなたの企業のIT部門に成り代わってし続けなければならない。サービスを続行する以上、ベンダーはこれらの維持作業をせざるを得ないが、他のベンダーに対して優位性を持ち続けることは資金や他者の破壊的なテクノロジー革命によって困難になるかもしれない。

クラウドサービスの互換性が無い現在、企業が自社のシステムの大部分をクラウドに預けるということは上記のリスクから考えづらいところである。現状の市場の動向を見ても、システムテストのためにAmazon EC2を曲がりする。業務の一部分をSaaSに移行するといった部分的な使用に留まっていることが分かる。日本政府の次世代システムの研究でも、クラウドの間をスイッチする技術というのがテーマとして挙がっているのもなるほどというわけである。

世界のコンピューターが５台になるクラウド時代のためには、企業、あるいは個人が特定のクラウドサービスにロックインされないようにする標準化、互換性維持方法の策定などが不可欠なのである。これがうまくいかないとクラウドはバズワードかつ部分的な普及で終わるだろうし、万が一ユーザーが騙されてしまったとすると、クラウドベンダーにロックインされる、オープンシステム以前の暗黒時代に逆戻りすることになるだろう。

Google Japan Blog: Google Chrome OS のご紹介

GoogleがWebプラットフォームに最適化された独自OSを発表したニュースで今日は持ちきりでしたね。

Google Japan Blog: Google Chrome OS のご紹介

Chromeの速さには感動しているので、Chrome OSが発表されたらすぐに使ってみようと思います。

Linuxベースで作るということですが、Webの実行に最適化してシンプルにするのでセキュリティーも強化されるとのことです。コードの量を減らせば脆弱性・脅威の発生確率は落ちるのでこれは正しいでしょうね。Microsoftが現在のWindowsのセキュリティーレベルを達成するためにどれだけの投資をしたかを考えるとMicrosoftがかわいそうになります（巨大化したOSのコードをさらって穴を潰していくのは非常に大変なはず）。セキュリティー対応と言えば、SSLクライアント証明書対応もお願いしますね＞Googleさん

Chrome OS、ちょっと心配なのがUIです。Chromeの設計思想はブラウザを出来るだけ黒子にするということなので、Chrome OSでもUIは最低限のものでシンプルにすることが予想されますが、AndroidのUIとiPhoneのUIを比べてみてしまうと、現在のAndroidのUI実装のようなちょっとイケていないUIがChromeに持ち込まれたら嫌だなぁと思ってしまいます。Googleのデザイン責任者だったボーマン氏（Twitterに移ってしまった）がいなくなったというのもUIのデザイン面についての不安を煽ります。

それから思ったのが、Chrome OSとサービスを提供するクラウドの関係って、昔のダム端末とメインフレームの関係をそのままにプロトコルをHTTPに持っていったものだってこと。歴史は繰り返すというのはまさにこのことですね。まぁクライアントで出来るケーパビリティが全然違うということはありますけどね（数十年前のテクノロジと最新のものを比べたらかわいそう）。こういったパラダイムの転換によって設計がやり直されすっきりすることは良いことだと思います。シンプルに書き直すことでセキュリティー強化や資源の有効活用による環境問題への対応が図れると思います。私は無駄に複雑で重たい実装が嫌いなのです。

ホッピーが好きだ

IT関係の人は若い人が多いのでホッピーのことを知らない人も多いと思う。会社の飲み会でホッピーが置いてあるお店に行ったことがあって、喜んで飲んでいたら、「それ一体なんですか？」と怪訝そうな顔で見られたことがある。

ホッピーとは発泡酒の祖先みたいなもので、ビールテイストの代替飲料である。ホッピービバレッジという会社が戦後のビールが手に入りづらい頃に作ったものだ。昭和の飲み物である。

ホッピーは単体ではアルコール度が殆ど無い（ゼロではない）ので、焼酎で割って飲むことになる。割る焼酎として最適なのは俗に言うキンミヤ焼酎という甲種の焼酎だ。

ホッピーを飲むきっかけになったのが自分の尿酸値の高さ。悪化すると通風になると言われる高尿酸値症というやつだ。実際に足が痛くなって病院で検査したこともあるのだが、そのときは症状が軽くて通風という診断にまでは至らなかった。しかし、毎年の血液検査では要観察という結果になるので予備軍であるのは間違い無いようだ。

ビールを飲むのが好きなのだが、ご存知の通りビールは尿酸値を上げる因子であるプリン体を多く含むので尿酸値に良くない。（実際には魚卵系がもっと悪くて、私はフォアグラを食べると通風の軽い発作が一発で来る）ホッピーは焼酎で割って飲んだとしてもプリン体がかなり低いので安心して飲めるというわけだ。

正直言って、ホッピーにビールの味をそのまま期待するとがっかりすることになると思う。最近の第二のビール、第三のビールのほうがよほどビールに近い味がすると思う。ホッピーは似非ビールテイストを楽しむ飲み物なのだ。

ちなみにホッピーは今では東京の下町近辺を中心に商売をしているようで、関西でホッピーを飲むのはかなり難しいらしい。（飲み屋でも数件しか扱っていない模様）キンミヤ焼酎なんてものも私は今住んでいる下町に引っ越してくるまでは見たことが無かったのだが、近所のスーパーや酒屋には皆置いてあるので下町限定で需要が多いのだろう。

飲み屋に行くと、良くチューハイのように氷を入れたジョッキとホッピー＋焼酎が出てくることがあるが、これは邪道だそうである。本来はキンキンに冷やしたジョッキあるいはグラスにこれまた凍る寸前まで冷やしたキンミヤ焼酎を入れて、そこにホッピーを注ぐのだそうだ。家ではグラスを冷やすまではしないが氷を入れない飲み方で飲んでいる。近所の酒屋さんでは業販用のホッピー（量が小売のものよりも多い）を配達してくれるので、ケースで買って飲んでいる。

Simplicityについて

IBM丸山さんのブログより

やはり社内の議論で、複雑になりすぎたソフトウェアをどうしたら簡単化できるか、と言う議論がありました。複雑さを扱う戦略のもう一つの方法は、抽象化です。でも、今のソフトウェアは、OSやミドルウェアの抽象化のレイヤーを重ねすぎて、かえって複雑になっているようです。アブストラクション・リーケージ（抽象化の漏洩）という言葉があって、せっかく抽象化のレイヤーを作って実装の詳細は隠したのに、性能やセキュリティやその他のいろいろな非機能要件を追い求めていくと、結局実装が透けて見えてきてしまう、というものです。

私も同じことを感じています。IBMが推進しているJ2EEにしろ、Microsoftの.NETの世界にしろOS、コンテナ、フレームワーク、アプリケーションコードとスタックが複雑化しすぎています。レイヤーごとに抽象化することによって、プログラムコードの開発者に見える部分が単純化したりポーティングを容易にする効果があるのですが、トラブルの際に低いレイヤー（コアダンプの解析、ネットワークのトレースなど）から高いレイヤーまで見ないと行けないような場合にはこの複雑化した環境に本当に苦しめられます。

以前JavaのVM自体をOSにしてしまおうという動きがありました、Javaの上でコードを書くことを前提にするのであれば、下で動くOSをJVMと一体化したほうが最適化出来てシンプルで良いのでは無いかという考え方です。残念ながらこの試みは普及するには至りませんでした。

最近ではクライアントサイドはWeb、言い換えるとブラウザ自体がプラットフォーム化しようとしてきています。プラットフォームの主戦場はミドルウェアの世界からブラウザ上で実行されるコードの世界に移行してきているように思えます。HTML 5で提案されている機能はブラウザ単体でのリッチな機能の実装を目指しており、OSのレイヤをバイパスしようとする意図が見え隠れします。Java OSが目指したようにブラウザ自体がOSであるという考え方になるのかもしれません。

サーバー側はクラウド、クライアント側はHTML 5対応のブラウザという世界になった場合、開発者の労力は下がりますが、私のような裏方の世界を支えるエンジニアはどうなるでしょうか？現在と同じように裏側のスタックが単純化されていないと苦労は変わらないと思います。ただ、あまりにもバリエーションがありすぎる現在の企業システムがある程度テンプレート化したクラウドに移行することによってサポートしなければいけないテクノロジーパターンが減ることは期待出来ると思います。