しかしまぁ、利用者不在の議論を続けてるな・・・と。まぁ、新経営陣の特色を出したいのだけど、それに振り回される利用者の身にもなれ！、と言いたい。まぁ、目先の経費削減を優先した形なのだろうが、中長期的に見ればどうだろうね。
ワールドワイドに見ればデルタ・スカイチームのネットワークのほうが大きいのだし、利用者にとってもメリットは大きいはず。個人的な思いを別にしても、またアメリカンとの提携に戻る理由は見当たらない。
国内線をＪＡＬに乗り換えようかと思ったのだけど、やっぱり、これまでどおりＡＮＡにしておこう。サービスもいいしね。
まぁ、頑張ってくれたまい！、いなもりさん。
金曜日を休んで出かけた恒例の田沢湖。もうかれこれ十数年、毎年あつまって滑ったり飲んだり、温泉に入ったりしている。今年は関東勢の都合がちょっとわるく、参加者が少なかったのだけど、かわりに？久しぶりの人も来て、なんとなくこじんまりとまとまった。
宿はもう定宿になっているCafe and Inn "That sounds good" 、ジャズ好きのご主人が、時々ライブなんかもやるので、ホールにはピアノやドラム、ウッドベース、ギターなどが並んでいる。
田沢湖畔の木立に囲まれた宿。冬はこうして雪景色。夏は青葉に囲まれる。
食堂、娯楽室をかねたホールには楽器がいっぱい・・・。壁にはレコードのジャケットなんかも飾られている。BGMもそれっぽいのがずっと流ていて、なかなかいい雰囲気。
この雰囲気で飲むビールはまた格別だ。スキーもそこそこに、温泉に浸かって、宿に帰り、まずギネスを・・・というのが毎年のパターン。
毎年ならば、木曜の夜から徹夜で車を走らせ、金曜日は朝から滑って・・・という形なのだけど、ちょっと今年は単独での徹夜ドライブをする体力と気力に自信がなかったので、金曜日を１日移動日にしてしまった。まぁ、どちらかといえばスキーよりも、みんなでわいわいやるのが目的でもあるので、夜の宴会までに間にあえば・・・。
でも、今年は例年になく雪が多くて、しかも気温が低い。昼間でも氷点下。北海道ほどではないが、昨日は新雪を堪能できた。
まぁ、大人のスキーなので、朝から３本滑って休憩、３本滑って昼飯・・・てな雰囲気。昼飯は、適度にすいた腹にまかせて、がつん！っと・・・・。この焼きそば、昨年、秋田であったB1グランプリの優勝メニューらしい。なぜか、地元横手の焼きそばだけではなく、優勝を争った静岡の焼きそばも売っている。一皿に両方盛った「対決」メニューも・・・・。まぁ、味は悪くないけど、大盛り食ったら、午前中の消費カロリーではおつりがくる。
食事をしてたら天気が回復したので、ちょっと食べ過ぎた分を消費すべくまた滑りにでた。普段はコブ斜面になる黒森ゲレンデだが、今日は新雪。まぁ、この時間だと残ってはいないだろうと思いながらも、多少期待しながら行ってみた。このコースは天気がいいと、田沢湖が綺麗に見える。南斜面なので、雪がゆるむのも速いのだけど。
下から見ると、もう残りはないように見えるけど、結構、まだ残り物はあったりする。ちょっと重いので、北海道仕様板（センター幅108mmの太板）では、思い切り体重をかけないと沈まないのだけど、それでも、この「ばふっ」がたまらない。
調子にのって5本も滑ったら、太ももも売り切れて、めでたく終了。てか、ちょっとがんばりすぎて、膝にきてしまった・・・。
天気が良かったのは、この一瞬だけ。山を下りるころには、また雪が降り出して、前が見えないくらいの雪になった。
この雪の中を、3時過ぎに到着する仲間を迎えに駅まで行ったのだけど、前も、道の左右もよく見えないので、結構、運転は辛かった。
んで、まぁ、また宴会をして、昨夜は早めに就寝。今朝は、またいい感じで雪が積もってた。帰りがきついので、滑らずに帰ろうと決めてはいたのだけど、ちょっと気持ちが揺らぐ一瞬。
まぁ、いずれにせよ車は動かせないと・・・ということで、朝から雪かき。結構、いい運動になった。
朝霧の田沢湖。なんとなくいい感じだ。
そして朝食。この宿の食事は、結構手がかっていて、見た目も味もいいので、仲間内では人気だ。
後ろ髪を引かれながらも、明るいうちに家に帰りたかったので、皆さんとはお別れ。盛岡経由で帰ってきた。最近、道路工事でこういうのをよく見る。これはうさぎバージョン。昨年夏に実家に帰ったときは、タヌキバージョンがあった。ほかにもいくつかバージョンがあるみたいでなかなか楽しい。
東北道に上がって、ふとメーターを見たら、数字が４５６７８と並んでいる・・。ちょっと小人さんに頼んで撮影。（笑）この縮小版ではちょっと見にくいけど、距離計が連番になってる。実はこの車、もう7年乗っているのに、まだこの距離。最近車に乗らなくなったなぁ。
とりあえず、仙台を超えるまでは一気に・・・と菅生まで走って昼食。また思わずアブナイ食べ物を食べてしまった。しめて１０３９キロカロリー也。いや、忘れよう・・・・・。
浦和料金所を過ぎたのは、午後3時半くらい。料金は盛岡から1700円也。久喜から浦和までは1000円路線の対象外なんだよねぇ。でも、行きは9800円ほどだったから、これはえらい差だ。で、そのまま首都高で湾岸へ出て、羽田から横羽線経由で鶴見まで走って、国道1号線沿いのコイン洗車で車を洗って家に着いたのが5時前。最近、スカイツリーが東京のあちこちから見えるようになった。これでもまだ半分にも届いていないのだから、完成したらどんな景色になるのか、楽しみだ。
で、家へ帰って、洗濯をしながらちょっとデジカメ画像の整理をして、これを書いている。いい感じの夕暮れ。今日は空気が澄んでいるのか、富士山のシルエットがくっきりと見えた。
さて、軽く晩飯でも食って、風呂に入ってゆっくりしよう。明日からまた仕事だ。
田沢湖スキー場。今日は朝から雪で、いい感じ。でもかなり寒い。とりあえず昼飯までにパウダーエリアを６本ほど滑って、終わり！、と思ったら天気が良くなってきたので、また滑りに出た。もう、パウダーは食いつくされていたと思った斜面で、食い残しを見つけたので、思わず５本ほど・・・。ちょっと太もも売り切れ状態で終了。
今日はお休み。例年のごとく、田沢湖畔の定宿にて・・・。今年はスキーよりも温泉、宴会中心で・・・って、ここ何年かはそうじゃん？。
今回は、いつものメンバーで都合がつかなかった人も多くて、こじんまりとした集まりになってるけど、それもまたよし・・・。いつもは徹夜で走って、朝一番から滑るのだけど、今回は朝、家をでて、午後３時ごろ到着。宿に直行してひと風呂浴びてビール・・・・それもまた・・・・。気温がかなり下がっていて、盛岡から田沢湖に抜ける仙岩峠の上で、午後２時半に－９度。今夜降れば、明日の朝は期待できそう。
さて、まったり飲むか・・・
ＯＳの上には当然ながら、様々なアプリケーションが載るのだが、ＯＳから見たアプリケーションとしてではなく、サービス側のプログラムから見ると、間にもう一枚レイヤが存在する。いわゆる、ミドルウエアのレイヤである。
たとえば、Ｗｅｂアプリを機能させるためには、当然ながらＷｅｂサーバが必要だが、これらは、独立したパッケージ（商用、オープンソースを問わず）を使用する。また、アプリを記述する言語やその処理系、データベースなども、アプリケーションとは独立して、その直下のレイヤを構成する。ここまでのレイヤをサービス化するとPaaSになるのだが、そのレベルは様々だ。必要最小限のカスタマイズもしくは制限を加えたＯＳ環境のレベルから、ミドルウエアのレイヤをすべて統合して、アプリケーションから使いやすいＡＰＩとして提供するものまであって、ユーザの目的によって使い分けられる。
このレイヤでも気になるのが、これらのパッケージの脆弱性問題である。とりわけ、ネットワークレイヤに直接接するインターフェイスとなるミドルウエアは、外部からの攻撃やそれに伴うマルウエアなどの侵入というリスクにさらされることになる。これらがサービスとして提供されるならば、その部分の脆弱性対策は事業者側の責任だ。また、このレイヤでは、利用者側の不注意による問題や、悪意による問題を発見、もしくは防止、軽減するための措置を講じることもできる。ある利用者の挙動が、他者に影響しないような方策を講じておくことは基本だが、個々のユーザに対して、監視機能やより安全にサービスを使える機能を提供できれば、それが事業者の付加価値となるだろう。
ユーザがデータを保存するのもこのレイヤだ。ユーザが最も気にするのが、こうした情報の漏えいや破損、逸失である。これらについては、事業者、利用者の両面で対策を考える必要がある。最もわかりやすい分け方は、事業者は自分たちのファシリティや従業者の問題によって情報漏えいや破壊が発生しない対策をきちんと講じておくことが必要だし、利用者側は、扱う情報をきちんと仕分けして、事業者を使うことによるリスクを許容できるもののみを保存する必要がある。もちろん、利用者側が補完的な対策、たとえば独自の暗号化による保護策などを必要に応じて講じることができれば、クラウドの利用範囲はより広がるだろう。また、サービスを使うにあたってのアカウントの管理はほぼ１００％がユーザ側の責任である。これは、自社システムと、まったく同じ考え方で管理する必要があるだろう。
（続く）
・・・って、もうずいぶいん早い時間から雪にかわってるし。会社のかえりがけ・・・。
汐留から新橋、日テレあたりでもう雪になってた。
新子安まで帰ってきたら、一段と雪は強くなって、駅前の歩道橋にはミゾレ状の雪が積もって、滑りやすくなってて、ちょっと危険。
まだ結構降ってるから、明日は一面、銀世界かも。でも、雪に脆弱な都会じゃ、これは迷惑以外のなにものでもないかも。勘弁してほしいな。
でもまぁ、今週末のスキーは楽しそうだ。
【追記】ありゃ、もうこんなになってるし・・・・。まぁ、これも風情ですかね。
さて、ここまでの話は完全に事業者側の問題だが、ここから先は、サービスの形態によって対応責任の所在がかわるので注意が必要だ。
一般に、仮想化レイヤのすぐ上には、個々のゲストＯＳつまりは論理的な意味でのホストが存在する。一般にＩａａＳ事業者のサービスでは、ここから上の管理はユーザの責任となる。ＯＳそのもののセキュリティについては、いまさら言うまでもない。それを含めてＯＳのパッケージとして提供されるアプリケーションなどに関する脆弱性対策、ＯＳアカウントやＯＳに対して論理的、物理的に割り当てられているリソースへのアクセス制御、ネットワークアクセスの制御、マルウエア対策などについてきちんと考え、必要な対策を実装していくこと。そしてその見直しを適時に行うことである。仮想化システム上のＯＳとて、問題はまったく同じだから、１台のサーバを管理するのと同じことをすればいい。仮想化環境は、一種の仮想データセンタであるともいえる。そういう意味では、個々の仮想ホストが攻撃を受け、侵入された際のリスク（たとえば踏み台攻撃）、ネットワーク的にはそれが物理的なものか論理的なものかというだけで、まったく違いはないだろうから、論理的にネットワークを分離するとか、仮想アプライアンスとしてのファイアウォールを導入するとかいう対策も考え方は同じだ。この部分の管理責任は、ＩａａＳ事業者との契約形態やユーザのシステム構成によるだろう。
もし、複数のゲストＯＳと仮想スイッチのような環境を含めて、ユーザに管理権限が委譲されているならば、ユーザの責任はより重くなる。仮想的なネットワークの管理も含めて行う必要があるからだ。しかし、これも一般のデータセンタへのアウトソーシングとは特にかわらない。問題が増えるとすれば、仮想化システムのバグ等で、たとえば設定ミス等が他のユーザにまで波及してしまうことだ。この点においては、事業者側が適切な対策を講じる必要があるし、もし、そのリスクがあまりに高いようであれば、この部分の管理権限は事業者自身が押さえてしまうことが必要だろうと思う。ユーザの自由度を下げることにはなるが、安全性やユーザ側での管理の負担は大幅に改善するだろう。
唯一増えるリスクは、ひとつ下のレイヤでの脆弱性の影響で、侵入されたホストから本来は許されない操作が可能になってしまう可能性だが、これについては前段で述べたとおりだ。事業者としては、仮想ホストの管理について、こうしたリスクを下げるために利用規約上にガイドラインを設け、必要に応じてその手段を提供することで、ユーザにゆだねた管理のレベルを最低限の水準以上に揃えるという対応も考えるべきだろう。これはユーザにとっても大きな手助けにもなる。
（続く）
一般には最下層ととらえられてしまっているのが、本来、先に書いたような分散環境の上に構築されるべき仮想化レイヤである。最初に断っておくが、私は、こうした分散環境をまったく持たない仮想化環境は、単なるサーバ統合以外のなにものでもなく、「クラウド」などとは呼べない代物だと思っている。少なくとも、複数ＤＣ間でのダイナミックな形での処理分散、多重化が行われている必要がある。もちろん、理想形は先に書いた形であるが、百歩譲っても、（地理的な意味での分散も含め）最低限の分散環境を持たないクラウドはありえない。
苦言はさておき、仮想化層で一般にリスクとされているのが、ハイパーバイザの脆弱性問題だ。既に過去において、本来完全に分離されているべき個々の仮想ホスト環境とハイパーバイザの機能が脆弱性によってアクセス可能になる、といった問題が発生している。仮想化が進めば、そうした問題を悪用するマルウエアなどが出てくる可能性もあるし、ハイパーバイザを経由してバックヤードに存在する共有リソースが狙われる可能性もある。
こういうと、危なげに聞こえるのだが、このリスクはどれだけのものなのだろうか。たしかに、個々のホストが独立している環境に比べれば新たなリスクではある。だが、一方で独立したホストでも脆弱性問題は存在するし、それを狙ったマルウエアが蔓延するリスクもある。大変なのはむしろこうしたホストの管理であり、それは仮想化環境でもそうでなくてもかわらない。ハイパーバイザの問題については、事業者がどれだけ真面目に脆弱性対策や監視を行っているか、という点に尽きそうに思う。また、たとえば、仮想化ホストの場合、事業者側でテンプレート的な仮想環境を用意しておき、ユーザに提供するｊことも可能だ。このテンプレートの中に、標準で必要最小限のセキュリティ機能を入れておくことで、仮想ホスト全体のセキュリティベースラインを揃えることもできるし、必要に応じて集中監視、制御も一つのコンソールからできる。サーバ貸しでも同じことはできるが、単純にファイルのコピーですむ仮想化システム上での作業とは違い、手間がかかるから、コストも高くなりそうだ。
あとは、仮想化環境上で、ユーザのリソース（ストレージやネットワーク、ＣＰＵ、メモリほか）をきちんと管理し、相互に影響しないように分離することだろう。つまり、あるホストに問題がおきても、他のホストに影響しないように設計されていなくてはならない。しかし、これも、なにも仮想化環境だけの話ではないし、仮想化環境ならば、論理的に構成が可能なので、より作業は容易になるだろうと私は思っている。
そういう意味ではこのレイヤの問題もほぼクリアになっているだろうと私は思う。「脆弱性対策」という意味では、いわゆるベストプラクティスを淡々とこなしていくしかないのだろう。対策とモニタリング、そして最新情報の入手と対応の見直しというマネジメントサイクルがきちんと成熟した形で実装されている事業者ならば・・・の話ではあるのだが。そういう意味では、（個人的にはあまり信用していないのだが・・・）ＩＳＯ２７００１（ＩＳＭＳ）認証などは、利用者にとってはひとつの判断材料になるだろうと思う。
（続く）
まずは、レイヤ別の整理をしてみよう。クラウドの基盤が大規模分散環境、その上の仮想化基盤であるとするならば、まずはそれらに対する脅威、脆弱性とそのインパクトについて整理してみよう。言うまでもなく、このレイヤは事業者の守備範囲だ。
まず、分散環境だが、ネットワークを使う以上は、ネットワークからの攻撃の脅威にさらされることは間違いないだろう。ただ、ＶＰＮのような形でデータセンタ間のネットワークを作るのだとすれば、盗聴や侵入などの脅威はかなり低い（あえてゼロとはいわないが）と見ていいだろう。注意すべきなのは、マネジメント系システムへのアクセス制御だ。ここに侵入されないようにしないと、リスクは重大なものになる。ネットワーク的なアクセス制限をかけた上で、複数の認証機構を用意しておくことが望まれる。また、複数のセンターに分散する環境では、各センター内の基盤システムの運用は分離したほうがいい。このレイヤの保守・運用は基本的にはセンター単位でクローズした形で行い、管理機能は拠点で集中管理するような形がリスクが最も低いだろう。さらに、各センターに置くデータは暗号化もしくは秘密分散的な形で難読化して、鍵を管理拠点のみで管理しておくことで、データ漏えいのリスクは各センターのレベルではなくなる。管理拠点（複数）以外は管理機能にアクセスできないようにしておくべきだ。また、管理上の不正行為も大きなインパクトがあるので、管理拠点が複数あるならば、相互監視を、また、単一の拠点ならば、管理と監視の職務権限分離を行っておくべきだ。もちろん、各センタのファシリティの安全管理も十分に行っておく必要があるが、先に書いたようなセンタ間の機能分離が行われていて、さらにシステムが複数拠点に分散、冗長化されている前提では、ひとつのセンターでのインシデントはサービスダウン的なもに限られるので、システム全体に与えるリスクは性能の低下くらいだ。これは、災害対策的にも有効である。
ちなみに、こうした形態での分散環境が提供されている「クラウド」事業者は、現在のところ私が知るかぎりではＧｏｏｇｌｅのみだ。単に、検索エンジンのおまけとしてのサービスだから安い、というよりは、もともとこうしたコンセプトで設計されたシステムだからこそできていることなのかもしれない。気になるのは、セキュリティだが、このあたりはまだ想像の域を出ない。公式ブログによれば、今年（２０１０年）にはＧｏｏgle Ａｐｐｓに対して米国政府基準である FISMA （連邦情報セキュリティ管理法）対応認定を取得するとの話だ。ちなみに、誤解している人が多くいそうなので付け加えれば、同時に表明されている米国政府向けのコミュニティクラウドとＦＩＳMＡ対応の話は別物だ。ＦＩＳＭＡは一般のエンタープライズユーザ向けのシステムもカバーする。一方、政府向けクラウドはそれに加えて、より高度な要求に対応すると公式ブログには書かれている。こうした独自システムのセキュリティを測るには、このような認証や第三者監査による情報にたよるほかない。事業者には、是非積極的な取得や情報開示を求めたい。
（続く）
最近のコメント