このブログは「風見鶏」が、日々気づいたこと、思ったこと、したことを気ままに綴る日記です。2008年9月に旧ブログから引っ越しました。バックアップをご覧ください。

ゲストログインがうまくできないので、コメントを承認制にしました。スパムでないことを確認の上、公開します。判断はあくまで「風見鶏」の主観で行いますので、文句は受け付けません。(笑)承認が遅れることもままあると思いますが、あしからず・・・

システムトラブルのため、2015年以降のブログ画像と2018年5月以降の記事が消失しました。画像は鋭意、新しい物から順次復旧中ですが記事については残念ながら戻せません。残念ですが、あきらめます。

なお、ここに書いていることは、あくまで個人的な思いであり、いかなる組織をも代表、代弁するものではありませんし、無関係ですので念のため。

雲をつかむ話(3章-9)

| コメント(0) | トラックバック(0)

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

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

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

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

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

(続く)

トラックバック(0)

トラックバックURL: https://www.kazamidori.jp/MT/mt-tb.cgi/265

コメントする

月別 アーカイブ

この記事について

このページは、風見鶏が2010年2月16日 07:37に書いた記事です。

ひとつ前の記事は「週末スキー(という名の宴会!?)」です。

次の記事は「雪の朝と・・・」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。