2010年2月アーカイブ

ちょっと私的な旅行で、サンフランシスコを経由して、南の島に行ってきます。ＳＦ経由の意味は、来週から開催のＲＳＡコンファレンスがちょっと気になっているからなのですが、すこし覗いたら、本来の目的であるハワイに行こうかと。

RSAに行きたいのは、クラウド関連でどんな話が出てくるか、ベンダはどんな動きか・・・といったあたり。それって仕事じゃん！！、って突っ込みはなしに・・・。まぁ、今の仕事はほとんど趣味なので、こういうのもありかなと。趣味だから出来ることもあるし。

ハワイは、いつもならオアフは遠慮するのだけど、今回は実質的にまる２日しか滞在しないので、オアフステイ。さすがにワイキキあたりで２日過ごす気にはならんので、到着当夜は空港近くに止まって、あと２日はノースショアに宿をとった。ハレイワあたりでも散策しながらまったりしようかなと思ってますが・・・。

さて、搭乗まであと１時間、このペースでビールを飲んでると完全に出来上がってしまうので、とりあえずウーロン茶に切り替えて・・・・

では、行ってきます。

雨の志賀高原。もう滑るのはやめようかと思ったのだけど、一旦、雨があがったので、回数券を買ってゲレンデに出てみた。焼額はゴンドラが強風で止まって、リフトが２本しか動いていないので、とりあえず一之瀬方面にエスケープして、ダイヤモンドを何本か、

向こう側は一之瀬なんだけど、歩道橋を渡るのが面倒なので、こちらがわを４本ほどかっ飛んでいたら、また雨がひどくなてきた。

で、早々に退散することにして、焼額方面への連絡コースを滑降・・・・。シャーベット状の雪は意外とスピードがのる・・・・。

第二高速を１本滑って昼食。お昼はねぎとろ丼、具だくさんの割に主賓のねぎとろは少なかったりするのだけど・・・

外は雨・・・・。レストランのガラスにも雨粒が・・・。エントランスに雪はなく・・・となんとなくさびしい２月末の志賀高原

で、早々に回数券を使いきって、引き上げ、山を下って湯田中温泉へ。まだ、ＪＮＳＡの本隊は到着していないので、しばし旅館のロビーで休憩

やっぱり、歴史のある温泉街だけあって、なんとなく風情がある。

３時間ほどの会議のあと（いちおう幹事会なので）夕食。なかなか立派なお膳。

若女将の口上も老舗の旅館らしい。

・・・んで、このあとは、お酒が入って・・・即沈没。だって、前日は３時起きだし・・・・

今朝は６時に起きて昨日は入れなかった温泉。で朝飯を食べて、現在まったり中。さて、もうひと風呂行ってこようかな。

SaaSのセキュリティといっても、表面について言うならば、いわゆるWebアプリのセキュリティだろうと思う。ユーザに委譲された範囲でのID管理はさておき、事業者側では、アプリケーションレベルでの脆弱性対策をしっかり考えておくべきだ。基本的には、不正入力に対するチェックをきちんと行って、インジェクション系の攻撃を防ぐことだ。ただ、一般のWebアプリとは異なり、基本的にマルチテナントでサービスを行うSaaSでは、ユーザ間のアクセス制御やリソースの分離にも神経を使う必要がある。たとえばデータベースを共用するような場合、アプリケーションからデータベースへのアクセス権限がユーザごとに分離されていないと、脆弱性に対する攻撃を正規のユーザが行った場合、被害は全ユーザに及んでしまう。基本的には、このようなことがないように、少なくともデータベースへのアクセス権限はユーザごとに管理できるようにしたい。

アクセスログの取得とユーザへの提供も重要だ。認証部分をSAMLなどで外出しできれば、認証ログについては、サードパーティーの認証サービスで対応できるが、データへのアクセスログはサービス事業者自身が提供しなければいけない。昨今の状況下では、情報の管理にアクセスログの取得が要求されるケースが多く、これが不可能なSaaSは、現実的には使いにくいのが正直なところだ。

SaaSの最も大きな特徴は、APIによるシステム連携が可能な点だと先に書いたが、多くの場合、このAPIは、XML Webサービス、つまりSOAPによって実装されている。表に見えるユーザインターフェイスとは違って、直接、コンピュータによってアクセスされるAPIは、自由度が高い分、リスクポイントも大きくなりがちだ。XML化されたデータの各要素がサーバサイドやクライアントサイドでどのように処理されるかによっては、不正入力が思わぬ副作用をもたらしてしまう。当然ながら、SQLインジェクションのような問題も生じることになる。最近は、Webベースのユーザインターフェイスにおいても、Ajaxのような非同期の仕掛けを使って、裏でサーバのAPIにアクセスしているケースもある。こうしたAPIの仕様は、たとえ公開されていなくても、ページのソースコードに記述されたスクリプトから簡単に読み解くことができるから、実際は公開APIとリスクの差はあまりない。ちなみに、ソース表示を禁止しても無駄である。そんなものは簡単に破ってしまうことができるからだ。

APIの問題はかなり複雑だ。単に、クライアントからサーバに渡された情報を、サーバ側がどう処理するかだけではなく、サーバからクライアントに渡されたデータをクライアントつまり、利用者側のシステムがどのように処理し、ユーザに表示するかも大きな要素だからだ。たとえば、なんらかの手段で、サーバ側から返されるデータに加工を加えることができれば、クライアントに対して副作用を引き起こすような内容を返すこともできる。サーバから持ってきた情報をそのまま使って、ユーザに表示したり、自前のデータベースに連携させたりする際に、この副作用が発生するとちょっと困ったことになる。つまり、ユーザは事業者のサーバから帰ってきた値を無条件に信用してはならないということだ。いや、すこしトーンを下げて言うならば、「信用しないほうが身のため」である。特に、ユーザインターフェイスへの表示や、データベース処理など副作用を起こしやすい処理に使う場合は、最悪の事態を想定して、きちんとサニタイズしておいたほうがいい。事業者、利用者の双方でこうした措置を講じることで、不測の事態が発生するリスクをかなり下げることができるだろう。

APIの話を除けば、SaaSレベルのセキュリティ問題の多くは事業者側の範疇にある。しかし、どうしても利用者側が逃れられないのが、自分たちのユーザの管理、つまり、事業者から買ったアカウント内部の管理だ。企業向けサービスの多くは、一定数のアカウントをグループ化して、利用者側で自由に管理ができるようになっている。契約数の範囲であれば、自由にアカウントの作成、変更、削除ができるほか、アクセス権限などの管理も自由にできるものが多い。また、そうでなければ一定規模以上の組織では使えないのも事実だ。だが、そうした権限委譲の結果、利用者側にも重い管理責任が生じる。たとえば、あるエンドユーザのパスワード管理が甘く、アカウントをクラックされ、情報を盗まれたとしても、一般にそれは事業者側の責任にはならない。事業者は、先にのべたように、ある利用者グループの不具合が他の利用者グループに影響しないようにする責任はあっても、利用者グループ内の問題には直接手出しができないからだ。

だから、SaaSの場合でもID管理はユーザ側の大きな責任である。この考え方は自社のシステムを使う場合とまったく同じである。しかし、自社システムの場合、必要に応じて自社の管理ポリシーに応じた機能を調達できるが、SaaSの場合、提供されている機能、たとえば、認証方法の選択肢や、パスワードなどの管理ポリシー（複雑性、変更頻度など）の強制の機能が不十分な場合も多い。ただ、先にもちょっと書いたが、多くの事業者のサービスで、SAMLやOpenIDといった標準的な方法で、認証を外部のサービスに委ねることができるようになっているから、これを利用して、自社のニーズに合ったシステムを自社に入れるか、認証サービス事業者のサービスを別途買うことで、自社のポリシーにあった仕様を満足する認証手段を得ることができる。自社で既にこうした連携が可能な認証手段を持っていれば問題ないが、新たに導入するのであれば、認証サービスを利用したほうが早いかもしれない。SaaS移行によって運用コスト削減をめざすのであれば、なおさらだ。ただ、認証サービスも一種のSaaSであり、「クラウド」の一部である。特に大規模なユーザは、そのサービスが本当に自社が要求する規模の負荷に対応できるのかや、安全を担保できるかなどをきちんと見ておく必要がある。認証サービス事業者には意外と小規模な事業者も多いから、今はよくても、将来的に収容するユーザ数が増えた場合に、きちんとスケールしない可能性もあるからだ。

さて、ここまでひととおりのセキュリティ問題を見てみた。既におわかりかと思うが、基本的な要素は、クラウドでも大きくは変わらない。ある意味、すべて応用問題なのだが、一方で、単純な応用ではなく少しひねって考えなければいけない問題もいくつかある。それは、おそらくは、クラウドの特質であるスケーラビリティを確保する手段に関連している。たとえば、マルチテナントモデルの採用によて、通常よりもリスクを高く見積もるべき問題もいくつかある。だが、テクノロジーが既出のものである以上、基本問題はすべて既出なので、考え方は大きくはかわらないと思う。

こうして整理してみることで、少しは漠然とした不安を整理することができたら幸いだ。

さて、技術的な問題はここまでとして、ちょっと厄介な問題にも触れておこう。４章では、いわゆる「想定外」がもたらす困難を考えてみる。

（３章終り：続く）

今日は某ＪＮＳＡの「拡大幹事会」（という名の温泉ツアー・・というと叱られるかな）のためお休みをとって、長野は湯田中温泉・・・ついでに、朝から志賀で一滑り・・・をもくろんだのだけど。焼額山のふもとで午前６時に＋７℃・・・。そればかりか、着替えたとたんに雨が降り出した。

正直、気持ちが萎えてます。しばらく待って雨が上がらないようなら、今日はやめにしようかと。

うーん、やっぱ極悪休暇でスキーはちょと行いが悪いということなんだろうか・・・ (;_:)

もう春の陽気だもんな～。今年はそろそろシーズン終了かなぁ

今日は、なんとなく暖かいいい天気だったので、朝から掃除洗濯、布団干しをして、それからいつもの定期診察に都内の病院へ行ってきた。先般の人間ドックで悪化していたLDL（悪玉）コレステロール値は改善していたものの、中性脂肪値がまた上がっていて、すこし食欲を抑えないとやばそうな感じ。最近、忙しさもあってよく腹が減るので、ついつい腹一杯食べてしまうのがよくないらしい。

一昨年からの、「うつ」治療は、なんとか最終段階に入って、段階的に薬を減らしているところ。ちょっと気分的に不安定になることもあるのだけど、全体的には悪くない感じだ。

昼過ぎに家に帰ってきて、あとはまったり・・・。録画した番組とか、DVDとかをちょっと見て、軽く昼寝して、洗濯物と布団を取り込んだら、綿埃がひどかったので、またちょっと掃除。そんなことをしている間にもう夕方になってしまった。今日も綺麗な夕景。

さて、晩飯を食いに出かけて、結局懲りずに丼物なぞを食ってちょっと後悔して、それから近所のコジマによってLED電球を何個か買って帰ってきた。自宅の照明の大部分は既にLEDに変わっているのだけど、残った何個かの蛍光灯バルブをLEDに交換。これで、うちの照明は、ベッドサイドの読書用蛍光灯スタンドを除いてすべてLED化された。全部つけても消費電力は１００Wに満たない。まぁ、うちの最大の電気食い虫は、照明ではなく、このブログを上げているサーバとか、ネットワーク機器類といって、一般家庭にはありえない物たちなのだけど、こいつらの省電力化は一気には難しいので、その他の部分で省エネをしようかと・・・。でもまぁ、PC関係はCore2ベースに変わっているので、以前のものに比べれば、消費電力は減っているのだけどね。テレビも昨年、低消費電力型にしたのだけど、まぁ、５０インチプラズマじゃ、それなりに電気は食うから、こまめに消すしかないし・・。あとは、エアコン。こればっかりは、なかなか切れない。結局、照明だけじゃ、焼け石になんとやらなのだけど・・・。

さておき、まったりと暮れていった土曜日であります。

いまさらながらに、こんなことを書くのだけど、個人情報保護法騒ぎ、Winny騒ぎ、JSOX騒ぎ、そして昨今のクラウド騒ぎを見ながら、あらためて思ったことがある。つまり・・・・

ITリテラシの低いセキュリティ屋は「役に立たない」ということだ。

何の役にたたないかと言えば、「ビジネス＝仕事」である。いまやITなしでは仕事ができないし、新しいIT技術をどんどん活用していくことが、ビジネス上での競争力に繋がる。２０世紀終盤に言い尽くされてきた言葉のはずだが、これを台無しにしてしまった奴らがいる。それが、ITを知らない、「自称セキュリティ屋」たちである。

最新の技術を使いこなしていくことがIT活用の本来の姿であるとすれば、その足を引っ張りつづけることは「悪」以外の何者でもない。たとえば、しゃぁしゃぁと「ノートPC持ち出し禁止」などというばかげた主張をしてしまう奴らだ。いったい何のために買ったノートPCなんだろうか。リスクがあるならば、それを回避して「使う」方法をきちんと考え出すべきであり、「使うな」ということでは決してないだろう。ビジネスは「待ったなし」なのだから、新しい技術が使われ始めてから使い方を考えたのではもう遅い。先回りして、安全な使い方を研究しておくのが、本来のITセキュリティ屋の仕事のはずだ。

どうしてそんな変なことになってしまうのか。そういう連中を、そんな仕事につけた人たちの責任も大きいから、彼らだけを責めてもしかたがないのだが、そもそもITがわからなければ、ITのセキュリティポリシーやガイドラインを決められるはずもない。IT部門の技術畑の意見は聞いても。技術的な本質がわからないから当然疑心暗鬼になってしまう。理解するでもなく、全面的に彼らを信用するでもない。結局、意見は半分に聞いておいて、ありきたりのベストプラクティスにたよってしまう。それならばまだマシだが、最悪なのは自分が責任を負えないから、（ありえないルールを作って、それを破った）人の責任にしてしまおうという連中だ。持ち出し禁止を唱えるような輩はそんな連中が多いと私は思う。

世の経営者の皆さんに言いたい。セキュリティ屋にするなら、IT畑のエース級にきちんと教育を施して育てるのが一番いいと。間違っても総務端や法務畑の余った人材を回すべきではない。ITを使いたいと思わない人間にITのセキュリティをまかせてはいけない。それは会社のIT活用を阻害し、競争力を損なってしまうからだ。

いまさらながらだけど、ふとそんなことを考えながら、怒りがこみ上げてきたので・・・・書いてみた。

＃リアルでのお仕事に関した愚痴ではないので、念のため・・・（苦笑）

なんだか明け方から寒かったのだけど、夜が明けてカーテンを開けてみて理由が判明。また雪景色だし。そりゃ寒いわけだ。

まぁ、例年、何日かはこんな日もあるので、驚きはしないのだけど、なんとなく寒さがきつく感じる、気分もちょっとどんよりとした朝。電車が遅れていなければいいけど、などと心配してたら、自分が家を出遅れて、危うく遅刻するところだった。

そういえば、故郷の冬は、ほとんど毎日がこんな感じだった。それも故郷を飛び出した理由のひとつに数えられなくはない。実際、スキー場の雪と、自分の生活圏での雪はまったく感じ方が違うから、人間というのは（・・とあえて一般化してみたりするが・・）勝手なものだ。午後から天気は回復するとのことだったので、今朝は始末に困っているビニール傘を持って出て、駅にある「善意の傘立て」に置いてきた。まぁ、この傘立てにはたまにお世話になることもあるから、たまには傘を提供しておこうかと。

しかし、仕事が多いので、なにかとバタバタしていて一週間が速い。もう木曜日・・・。でもまぁ、一昨年の忙しさに比べると、仕事が進んでいく爽快感があるので、ぜんぜん気分的には違う。報われない忙しさはごめんだが、こういう忙しさならば、むしろ望むところだ。さて、あと１日で週末。もう一頑張りしますか。

さて、話をレイヤ別の技術に戻そう。ミドルウエアレイヤのサービスを提供するＰａａSにおいては、そのうえで動作するアプリケーションが、提供される環境に大きく依存する一方で、利用者側にはある程度の自由度がある。これが、マルチテナントにおけるリスクを増加させていることは、間違いないだろう。このレイヤの障害やバグ、これがＣＩＡにかかわるものであれば、いわゆるセキュリティ問題になるのだが、これらは基本的には事業者側の守備範囲である。利用者側の自由度を高めれば利便性が増し、利用者にとってのメリットは大きくなるが、逆に、使われ方を想定した対策も考えにくくなる。これはビジネスとセキュリティのバランス問題あろう。いわばイージーオーダー既製服であるＰａａＳサービスを考える上では、利用者、事業者ともに難しい部分だ。

このレイヤでは、一部制限されたネットワークアクセス、データベースやストレージ、Ｗｅｂサーバやアプリケーションサーバと開発用言語などが、すぐ利用できる形で提供される。誤って、もしくは不正に使われる可能性がある機能については、特に、それが外部や他の利用者に影響をあたえることがないように、制限を加えたり、監視機構を組み込んだりすることは必要だ。これらから得られる情報は、基本的には利用者に対して(必要であればＮＤＡ下で）開示されるべきだろう。それによって、利用者は自分たちの守備範囲への責任をはたしやすくなるからだ。

利用者側は自分たちが作るアプリケーションに責任を負う必要がある。ＰａａＳ上に構築されるアプリケーションは圧倒的にＷｅｂアプリが多いが、今後、ＸＭＬ Webサービスベースのアプリも増加してくると予想する。これは、ＰａａＳを使うであろう利用者の多くが、一般ユーザを対象としたＳａａS事業者やスケーラビリティを求める大規模ユーザであることを考えると必然だと思う。これらについてのセキュリティ問題は既出だから、当然、そうした問題を回避する方策が求められる。この部分は、もうひとつ上のレイヤで併せて見ることにしよう。

さて、最後のレイヤがＳａａSである。これはいわば既製服だ。既製服にはスーツもあれば、ジャケット、ズボン、スカートなど単品もある。SaaSで提供されるサービスも同じような形だ。目的別の服を一揃えで提供しているサービスは使うほうも簡単だ。しかし、ちょっとヒネって着たい服があるように、サービスも違うものと組み合わせて使いたい場合もある。

スーツとして提供されるのが、既製のユーザインターフェイスやポータルアプリであり、単体として提供されるのが、個々の機能についてのＡＰＩと考えてみるとなかなか暗示的だ。セキュリティもこの２面から考えてみることにする。

（続く）

こちらも毎年恒例になっている、越後湯沢行き。岩原スキー場の麓の、とある旅館に泊まり込んで、宴会しながらその合間にスキー・・・てなことを、もうかれこれ１５年以上続けてる。金曜日の夜、車を走らせて湯沢入り。目標到着時刻は０時ちょい過ぎ。関越道、新座料金所－湯沢IC間￥１６００也はお得。

時間つぶしにSAごとに休憩。まぁ、眠気覚ましにはちょうどよかったかもしれない。高坂SAのイルミネーションが綺麗。宿に着いたら既に、宴たけなわ。でも、眠気には勝てず、1，2杯で即沈没。

最初の頃はパワー全開だった宴会も、参加者の年輪が増えるにつれ、まったりしてきて、スキーも、どちらかと言えば、お目当ては雪よりも岩原スキー場の中にあるピザ屋さんだったり・・・。

スキー場としては、言っちゃ悪いけど、だだっ広いだけのファミリースキー場だから、あまり面白みもないのだけど、毎年ここに来るのは、おいしいピザが主目的だからである。

今回は、とりあえずボードで参戦。今回滑っておかないと、今シーズンはボードを一度もはかずに終わってしまいそうだったので。だだっぴろい中央ゲレンデは、斜度もそんなにないし、広いからそこそこスピードを乗せても大丈夫。で、リフトの支柱（これはゲレンデのど真ん中に通っているリフトなので、リフト下通行はOK）でスラロームしてあそんでいたら、なんと食事前に6，7本すべるという無茶（スキーではないので・・・）をしてしまい、適度におなかもすいてたので、最高でありました。

とりあえず、ビールが入ってしまったので、スキー（ボードか・・）は終了。宿に帰って一風呂浴びて、夕食はスキー宿らしい、ガツンとくるやつを思わず完食。あとで酒が飲めず、ちょっとつらい思い。結局、昨夜も早々に沈没。

で、今朝は、まだ元気があるうちにと、早々に引き上げて帰ってきた次第。途中で車を洗って、午後1時半ごろに自宅着。それから洗濯、その他片付けと、録画してあった番組チェック。ちょっと昼寝、などしていたら、あっという間に日が暮れて・・・。

遠出したにしては、なんとなくまったりした週末でありました。

事業者のセキュリティについて言えば、よく調べると案外詳細な（というか適切な）情報が公開されている。たとえば、大手ＳａａSプロバイダのホームページやオフィシャルブログなどを見てみるといい。大手のほとんどが海外事業者だから、それなりの英語力は必要だが、公開可能な部分については、きちんと公開しているという印象を受けている。

一方、ブラックボックスが怖いという、ある意味での「都市伝説」がささやかれているのだが、それは本当にそうだろうか。セキュリティ情報の公開については、様々な議論はあるが、リスクゼロがありえない以上、そのリスクを下げるために情報を非公開にするというのも正しい判断のひとつだと思う。しかし、それでは利用者が実際のところどうなのかがわからないと困るから、第三者の監査を受けたり、セキュリティ認証を受けたりして、きちんとやっていることを客観的に評価してもらうわけだ。大手プロバイダもその多くが、なんらかの認証を取得している。はたしてそれで不十分だ、と言えるのだろうか。もちろん、いざインシデントが発生した時の対応への不安はあるのだが、それは大なり小なり、すべてのアウトソーシングに共通する問題だと思う。先にも書いたように、責任の分界点設定と価格のバランスの問題としてとらえるべきだ。コストを下げるには、利用者側も応分のリスクをシェアしなくてはならない。その意味はリスクをとる、というよりは自前で対策を考えるということだ。もちろんそのコストが、アウトソースの追加コストに比べて大きいものならば、その部分を事業者に任せるという判断もあるだろう。リスクそのものが小さいならば、とりあえず無視しておく判断もある。このあたりは、事業者、利用者の双方で少し意識をかえる必要がありそうだ。

インシデントハンドリングについて言えば、ハウジング主体のデータセンタへのアウトソースと、いわゆる共用リソースを使うホスティング、そしてそれをさらに進めた仮想化サービスでは、難しさが異なる。利用者ごとの環境の分離が難しくなるにつれ、インシデントハンドリングも難しくなる。マルチテナントのサービスを展開する事業者は、リソースを共有しながら、どのようにユーザごとのインシデントハンドリングを行うべきかについて、考えておく必要があるし、そのための機構も必要ならば導入しておくべきだろう。インシデントハンドリングにおいて、対象以外のユーザのデータにもアクセスしてしまう可能性がある場合、あらかじめそれを契約などに明記しておくべきだし、ハンドリングにあたっては、秘密の保持とその方法論も明確にしておくべきだと思う。なかなか安いサービスでそこまで要求するのは難しいとすれば、ユーザ側でのアクセスログなどをどの程度とっておけるかという点も重要だ。大きなインシデントが発生した場合、契約への記載の有無にかかわらず、利用者側で発生したものではないという証拠をある程度揃えて、事業者に対応を迫ることも可能だろうと思う。サービスを使うにあたって、認証部分をそのプロバイダ独自の機能ではなく、ＳＡＭＬやＯｐｅｎＩＤといった標準的な方法で、自社の認証サーバやサードパーティの認証サービスにゆだねるのも良い方法だと思う。多くの大手プロバイダのサービスはこれができるようになっている。また、認証サービス事業者側でも、マルティファクタ認証のサポートや様々なレポーティング、監視機能などを提供できるだろう。

（続く）

しかしまぁ、利用者不在の議論を続けてるな・・・と。まぁ、新経営陣の特色を出したいのだけど、それに振り回される利用者の身にもなれ！、と言いたい。まぁ、目先の経費削減を優先した形なのだろうが、中長期的に見ればどうだろうね。

ワールドワイドに見ればデルタ・スカイチームのネットワークのほうが大きいのだし、利用者にとってもメリットは大きいはず。個人的な思いを別にしても、またアメリカンとの提携に戻る理由は見当たらない。

国内線をＪＡＬに乗り換えようかと思ったのだけど、やっぱり、これまでどおりＡＮＡにしておこう。サービスもいいしね。

まぁ、頑張ってくれたまい！、いなもりさん。

金曜日を休んで出かけた恒例の田沢湖。もうかれこれ十数年、毎年あつまって滑ったり飲んだり、温泉に入ったりしている。今年は関東勢の都合がちょっとわるく、参加者が少なかったのだけど、かわりに？久しぶりの人も来て、なんとなくこじんまりとまとまった。

宿はもう定宿になっているCafe and Inn "That sounds good" 、ジャズ好きのご主人が、時々ライブなんかもやるので、ホールにはピアノやドラム、ウッドベース、ギターなどが並んでいる。

田沢湖畔の木立に囲まれた宿。冬はこうして雪景色。夏は青葉に囲まれる。

食堂、娯楽室をかねたホールには楽器がいっぱい・・・。壁にはレコードのジャケットなんかも飾られている。BGMもそれっぽいのがずっと流ていて、なかなかいい雰囲気。

この雰囲気で飲むビールはまた格別だ。スキーもそこそこに、温泉に浸かって、宿に帰り、まずギネスを・・・というのが毎年のパターン。

毎年ならば、木曜の夜から徹夜で車を走らせ、金曜日は朝から滑って・・・という形なのだけど、ちょっと今年は単独での徹夜ドライブをする体力と気力に自信がなかったので、金曜日を１日移動日にしてしまった。まぁ、どちらかといえばスキーよりも、みんなでわいわいやるのが目的でもあるので、夜の宴会までに間にあえば・・・。

でも、今年は例年になく雪が多くて、しかも気温が低い。昼間でも氷点下。北海道ほどではないが、昨日は新雪を堪能できた。

まぁ、大人のスキーなので、朝から３本滑って休憩、３本滑って昼飯・・・てな雰囲気。昼飯は、適度にすいた腹にまかせて、がつん！っと・・・・。この焼きそば、昨年、秋田であったB1グランプリの優勝メニューらしい。なぜか、地元横手の焼きそばだけではなく、優勝を争った静岡の焼きそばも売っている。一皿に両方盛った「対決」メニューも・・・・。まぁ、味は悪くないけど、大盛り食ったら、午前中の消費カロリーではおつりがくる。

食事をしてたら天気が回復したので、ちょっと食べ過ぎた分を消費すべくまた滑りにでた。普段はコブ斜面になる黒森ゲレンデだが、今日は新雪。まぁ、この時間だと残ってはいないだろうと思いながらも、多少期待しながら行ってみた。このコースは天気がいいと、田沢湖が綺麗に見える。南斜面なので、雪がゆるむのも速いのだけど。

下から見ると、もう残りはないように見えるけど、結構、まだ残り物はあったりする。ちょっと重いので、北海道仕様板（センター幅108mmの太板）では、思い切り体重をかけないと沈まないのだけど、それでも、この「ばふっ」がたまらない。

調子にのって5本も滑ったら、太ももも売り切れて、めでたく終了。てか、ちょっとがんばりすぎて、膝にきてしまった・・・。

天気が良かったのは、この一瞬だけ。山を下りるころには、また雪が降り出して、前が見えないくらいの雪になった。

この雪の中を、3時過ぎに到着する仲間を迎えに駅まで行ったのだけど、前も、道の左右もよく見えないので、結構、運転は辛かった。

んで、まぁ、また宴会をして、昨夜は早めに就寝。今朝は、またいい感じで雪が積もってた。帰りがきついので、滑らずに帰ろうと決めてはいたのだけど、ちょっと気持ちが揺らぐ一瞬。

まぁ、いずれにせよ車は動かせないと・・・ということで、朝から雪かき。結構、いい運動になった。

朝霧の田沢湖。なんとなくいい感じだ。

そして朝食。この宿の食事は、結構手がかっていて、見た目も味もいいので、仲間内では人気だ。

後ろ髪を引かれながらも、明るいうちに家に帰りたかったので、皆さんとはお別れ。盛岡経由で帰ってきた。最近、道路工事でこういうのをよく見る。これはうさぎバージョン。昨年夏に実家に帰ったときは、タヌキバージョンがあった。ほかにもいくつかバージョンがあるみたいでなかなか楽しい。

東北道に上がって、ふとメーターを見たら、数字が４５６７８と並んでいる・・。ちょっと小人さんに頼んで撮影。（笑）この縮小版ではちょっと見にくいけど、距離計が連番になってる。実はこの車、もう7年乗っているのに、まだこの距離。最近車に乗らなくなったなぁ。

とりあえず、仙台を超えるまでは一気に・・・と菅生まで走って昼食。また思わずアブナイ食べ物を食べてしまった。しめて１０３９キロカロリー也。いや、忘れよう・・・・・。

浦和料金所を過ぎたのは、午後3時半くらい。料金は盛岡から1700円也。久喜から浦和までは1000円路線の対象外なんだよねぇ。でも、行きは9800円ほどだったから、これはえらい差だ。で、そのまま首都高で湾岸へ出て、羽田から横羽線経由で鶴見まで走って、国道1号線沿いのコイン洗車で車を洗って家に着いたのが5時前。最近、スカイツリーが東京のあちこちから見えるようになった。これでもまだ半分にも届いていないのだから、完成したらどんな景色になるのか、楽しみだ。

で、家へ帰って、洗濯をしながらちょっとデジカメ画像の整理をして、これを書いている。いい感じの夕暮れ。今日は空気が澄んでいるのか、富士山のシルエットがくっきりと見えた。

さて、軽く晩飯でも食って、風呂に入ってゆっくりしよう。明日からまた仕事だ。

田沢湖スキー場。今日は朝から雪で、いい感じ。でもかなり寒い。とりあえず昼飯までにパウダーエリアを６本ほど滑って、終わり！、と思ったら天気が良くなってきたので、また滑りに出た。もう、パウダーは食いつくされていたと思った斜面で、食い残しを見つけたので、思わず５本ほど・・・。ちょっと太もも売り切れ状態で終了。

今日はお休み。例年のごとく、田沢湖畔の定宿にて・・・。今年はスキーよりも温泉、宴会中心で・・・って、ここ何年かはそうじゃん？。

今回は、いつものメンバーで都合がつかなかった人も多くて、こじんまりとした集まりになってるけど、それもまたよし・・・。いつもは徹夜で走って、朝一番から滑るのだけど、今回は朝、家をでて、午後３時ごろ到着。宿に直行してひと風呂浴びてビール・・・・それもまた・・・・。気温がかなり下がっていて、盛岡から田沢湖に抜ける仙岩峠の上で、午後２時半に－９度。今夜降れば、明日の朝は期待できそう。

さて、まったり飲むか・・・

ＯＳの上には当然ながら、様々なアプリケーションが載るのだが、ＯＳから見たアプリケーションとしてではなく、サービス側のプログラムから見ると、間にもう一枚レイヤが存在する。いわゆる、ミドルウエアのレイヤである。

たとえば、Ｗｅｂアプリを機能させるためには、当然ながらＷｅｂサーバが必要だが、これらは、独立したパッケージ（商用、オープンソースを問わず）を使用する。また、アプリを記述する言語やその処理系、データベースなども、アプリケーションとは独立して、その直下のレイヤを構成する。ここまでのレイヤをサービス化するとPaaSになるのだが、そのレベルは様々だ。必要最小限のカスタマイズもしくは制限を加えたＯＳ環境のレベルから、ミドルウエアのレイヤをすべて統合して、アプリケーションから使いやすいＡＰＩとして提供するものまであって、ユーザの目的によって使い分けられる。

このレイヤでも気になるのが、これらのパッケージの脆弱性問題である。とりわけ、ネットワークレイヤに直接接するインターフェイスとなるミドルウエアは、外部からの攻撃やそれに伴うマルウエアなどの侵入というリスクにさらされることになる。これらがサービスとして提供されるならば、その部分の脆弱性対策は事業者側の責任だ。また、このレイヤでは、利用者側の不注意による問題や、悪意による問題を発見、もしくは防止、軽減するための措置を講じることもできる。ある利用者の挙動が、他者に影響しないような方策を講じておくことは基本だが、個々のユーザに対して、監視機能やより安全にサービスを使える機能を提供できれば、それが事業者の付加価値となるだろう。

ユーザがデータを保存するのもこのレイヤだ。ユーザが最も気にするのが、こうした情報の漏えいや破損、逸失である。これらについては、事業者、利用者の両面で対策を考える必要がある。最もわかりやすい分け方は、事業者は自分たちのファシリティや従業者の問題によって情報漏えいや破壊が発生しない対策をきちんと講じておくことが必要だし、利用者側は、扱う情報をきちんと仕分けして、事業者を使うことによるリスクを許容できるもののみを保存する必要がある。もちろん、利用者側が補完的な対策、たとえば独自の暗号化による保護策などを必要に応じて講じることができれば、クラウドの利用範囲はより広がるだろう。また、サービスを使うにあたってのアカウントの管理はほぼ１００％がユーザ側の責任である。これは、自社システムと、まったく同じ考え方で管理する必要があるだろう。

このレイヤから上でサービスを提供する事業者の多くが、マルチテナントモデルをとっている。つまり、複数の利用者グループで一つのＯＳ環境を共有するものだ。マルチユーザＯＳにおけるアカウントのグループ権限管理を考えればわかりやすいだろう。事業者側がこの点で周囲すべきなのが、利用者グループ間のアクセス権限や利用リソースの管理強化である。ユーザアカウント（グループ）の管理は利用者側に委譲されており、基本的には利用者の責任だが、事業者は万一、利用者側の管理が不十分で問題が生じた際に、問題をその利用者内に封じ込めることができなくてはならない。

この問題は案外難しい。自社内のアクセス権限管理であれば、多少の悪意は考慮したとしても、管理を比較的ゆるやかにして、本当に重要なシステムは物理的に分離する、といったことも可能だ。しかし、マルチテナントの場合、悪意の存在はより深刻な問題になるだろうし、ユーザの質も様々なのだから、想定すべき事項やその程度は大きく異なる。たとえば、あるユーザがＣＰＵやメモリを過剰に消費しないような対策も必要になるだろう。もちろん、それでもさばける能力を提供するのがクラウドではあるのだが、利用者には応分の負担をお願いしなければならないし、それが利用者側の不注意や意図しない不具合などによる場合は、特に日本の場合はモメるもとになるからである。脆弱性管理について言えば、ネットワークから攻撃可能な脆弱性だけでなく、システム内での権限昇格など、ローカルのアクセス制御に介入できるようなものやサービス妨害的なものについてもきちんと対策が必要である。当然ながらシステムへのアクセス権を持つユーザの悪意や不注意をより強く意識しなければばらないからだ。

（続く）

こんな感じでいい感じの雪景色。幸いにも路上の雪はほとんで融けてる。

お天気も回復。今日はこれから、某協会の会合に直行です。

・・・って、もうずいぶいん早い時間から雪にかわってるし。会社のかえりがけ・・・。

汐留から新橋、日テレあたりでもう雪になってた。

新子安まで帰ってきたら、一段と雪は強くなって、駅前の歩道橋にはミゾレ状の雪が積もって、滑りやすくなってて、ちょっと危険。

まだ結構降ってるから、明日は一面、銀世界かも。でも、雪に脆弱な都会じゃ、これは迷惑以外のなにものでもないかも。勘弁してほしいな。

でもまぁ、今週末のスキーは楽しそうだ。

【追記】ありゃ、もうこんなになってるし・・・・。まぁ、これも風情ですかね。