Agile Cat — in the cloud

スマホ 利用にマッタをかける、米エンタープライズたち

Posted in .Selected, Byod, Mobile, Research, Security by Agile Cat on June 12, 2012

Mobile Security: Smartphones still ‘Enterprise Unready’
http://wp.me/pwo1E-4j8
By Dick Weisinger, on May 4th, 2012
http://www.formtek.com/blog/?p=2953

_ formtek

Enterprise networks are increasingly being accessed by mobile devices and that’s making a lot of IT professionals uncomfortable.  A recent report found that only 9 percent of organizations are aware of which mobile devices are accessing their networks.  And in another survey, two-thirds of organizations said that they had no way of identifying mobile device vulnerabilities.

エンタープライズ・ネットワークへの、モバイル・デバイスを介したアクセスが増大傾向にあり、数多くの IT スペシャリストの心配を煽っている。  最近のレポートでは、調査対象となった組織の 9% のみが、そのエンタープライズ・ネットワークにアクセスしている、モバイル・デバイスを把握しているという状況が報告されている。  また、別の調査では、対象となった組織の 2/3 が、モバイル・デバイスに関する脆弱性を、確認する手法さえ有していないとされる。

Nigel Stanley, security practice leader at Bloor Research, for example, went so far as to say that “Security people I work with are scared witless by consumerization and the rapid adoption of these devices.  Aside from the technical challenges, organisations need to understand the importance of a decent mobile device security policy and supporting user education.”

Bloor Research のセキュリティ・プラクティス・リーダーである Nigel Stanley は、「私がサポートするセキュリティ担当の人々は、コンシューマ化という言葉に取り乱すように怯えながらも、それらのデバイスを急速に採用し始めている。テクニカルな課題は別にして、それらの組織にとって必要なのは、適切なモバイル・デバイス・セキュリティ・ポリシーおよび、ユーザーに対する教育支援という、重要な事柄に対する理解である」とまで言っている。

imageRon Gula, CEO and CTO of Tenable Network Security, said that “Mobile devices add an entirely new level of complexity to an organization, but security too often takes a back seat to convenience”.

Tenable Network Security の CEO 兼 CTO である Ron Gula は、「モバイル・デバイスは、組織全体に対して新しいレベルの複雑さを加えていくが、多くのケースにおいて、セキュリティは利便性の後回しにされてしまう」と言う。

Raimund Genes, CTO of Trend Micro, said that “Against the growing, unstoppable backdrop of consumerisation and BYOD, every mobile device is a risk to business.”

Trend Micro の CTO である Raimund Genes は、「コンシューマ化と BYOD の増大という、止めることの出来ない背景があるが、その一方では、すべてのモバイル・デバイスが企業に対してリスクをもたらす」と言う

Gary Fish, FishNet CEO,  said that “Our company is seeing this as a major issue because of the number of BYOD (Bring Your Own Device) instances and the vulnerabilities that can threaten mobile computing, such as unsecured Wi-Fi access, lost or stolen devices, and malware attacks on mobile operating systems.”

FishNet の CEO である Gary Fish は、「私たちは、大量のBYOD (Bring Your Own Device)インスタンスと脆弱性が存在するため、モバイル・セキュリティを主要な問題とみなしている。たとえば、セキュリティを考えない Wi-Fi アクセスや、デバイスの紛失と盗難、モバイル OS に対する悪性ソフト攻撃といった、モバイル・コンピューティングへの脅威をもたらすことになる」と言う

A recent report by Bloor Research looks at the security features of the most popular mobile devices: iPhone, Android, BlackBerry, and Windows Phone.  The report concluded that “while some mobile platforms have evolved very noticeably along enterprise lines, there is still a strong ‘consumer marketing’ legacy in some quarters and this is negating some of the progress made on the enterprise front.  Indeed, some of the attributes we have examined in the report are still firmly ‘enterprise-unready‘.”

Bloor Research の最新レポートが注目するのは、iPhone/Android/BlackBerry/Windows Phone といった、人気のモバイル・デバイスにおけるセキュリティ機能である。 そのレポートは「いくつかのモバイル・プラットフォームは、エンタープライズでの要求に沿って、目覚しい進化を遂げている。 しかし、いくつかのプラットフォームには、依然として[コンシューマ・マーケティング]レガシーが存在しており、エンタープライズの領域で成し遂げられた進捗を、否定するものとなっている。実際に、このレポートで、私たちが確かめたところでは、[エンタープライズに対する用意ができていない]という、はっきりした結果が出ている」と、結論づけている。

Among all smartphones included in the Bloor study, RIM’s Blackberry device ranked as the most secure.  While BlackBerry has been on the defense lately trying to prop up a shrinking market share,  the BlackBerry OS is mature and still has a clear advantage over other mobile platforms in the area of security.  That may be the reason why the federal government purchased 400,000 RIM devices over the last year.

Bloor の調査に含まれる、すべてのスマートフォンの中では、 RIM の Blackberry デバイスが、最もセキュアなものとしてランク付けされている。  最近の BlackBerry は、先細るマーケット・シェアの防戦に追われているが、 BlackBerry OS は成熟しており、また、セキュリティの領域においては、他のモバイル・プラットフォームに対する、明らかなアドバンテージを有している。それは、昨年に連邦政府が、400,000台の RIM デバイスを購入した、理由になっているのかもしれない。

ーーーーー

TAG indexSaaS が到来すれば、従来からのエンタープライズ・アプリにおいても、使い勝手の面でのコンシューマ化が訪れるのかもしれません。 しかし、ビジネス環境から生じるアプリと、いわゆるコンシューマにフォーカスしたアプリには違いがあるはずです。デバイスだけで解決できる問題なのか? それとも、アプリを絡めた解決策があるのか? さらに言えば、SDN でネットワークを制御すべき問題なのか? これからの議論に注目していきたいですね。 ーーー __AC Stamp 2

ーーーーー

<関連>

BYOD – エンタープライズは生産性の向上とセキュリティ・リスクを秤にかける
企業データにアクセスするモバイルと、セキュリティとの関係を真剣に考えよう
最適な MDM(Mobile Device Management)ポリシーを構成するためには?
VPN が、次の IT トレンドを作るという 9つの理由
セキュリティ調査 – Sybase – ヒューマン・エラーが 48% で最大の脅威

 

NIST のクラウド定義はスクラップになるべきだ – その理由を説明しよう

Posted in .Chronicle, .Selected, NIST by Agile Cat on December 12, 2011

Why NIST Should Scrap “the Cloud” Entirely
Jon Stokes – 2011,11,12
http://www.wired.com/cloudline/2011/11/why-nist-should-scrap-the-cloud-entirely/

_ Cloud Line

The National Institute of Standards and Technology (NIST) has published a new volume of its roadmap aimed at accelerating the adoption of its previously released Federal Cloud Computing Strategy. The report lays out a set of 10 requirements for further federal cloud adoption, most of which will be familiar to any CIO who has the standard slate of worries about cloud’s interoperability, security, data portability, standards compliance, and privacy. Or, as NIST puts it:

National Institute of Standards and Technology(NIST)は、以前にリリースされた Federal Cloud Computing Strategy の適用を促進するために、新しい分冊としてロードマップを発行した。 このレポートは、連邦政府のクラウド適用に関して、10 個の要件セットを展開している。しかし、その大半は、クラウドのインターオペラビリティ/セキュリティ/データ・ポータビリティ/スタンダード・コンプライアンス/プライバシーに対して、不適切なスタンダードを信じることに慣れてしまった、CIO のためのものになるだろう。 すなわち、以下のように、NIST は言っている:

In the technology vision of Federal Cloud Computing Strategy success, [U.S. government] agencies will be able to easily locate desired IT services in a mature and competitive marketplace, rapidly procure access to these services, and use them to deliver innovative mission solutions. Cloud services will be secure, interoperable, and reliable. Agencies will be able to switch between providers easily and with minimal cost, and receive equal or superior services.

Federal Cloud Computing Strategy が成功するためのテクノロジーのビジョンにおいて、[ U.S. government ]の行政機関は、競争力を持つ成熟したしたマーケットで、必要とされる IT サービスを容易に見つけ出し、そこにへのアクセス権を迅速に調達する。続いて、革新的でミッション・クリティカルなソリューションを、それらの IT サービスを用いて展開していくだろう。 クラウド・サービスは、セキュアであり、インターオペラビリティの達成し、高い信頼性をもたらすものになるだろう。したがって、政府機関は、容易にプロバイダを切り替えられるようになるが、そのコストは最小であり、また、それまでと同等あるいは高品質なサービスを得られるようになる。

The only thing I’d add to this list is, “And every child should have a pony.”

私が、それに何かを付け加えることができるなら、“And every child should have a pony” 程度のものとなる。

Illustration: Richard Perez ⇒

Of course, it’s easy to poke fun at NIST’s pie-in-the-sky wishlist for cloud computing, but the authors themselves know that the document is more aspirational than operational. The plan is to identify priorities, to define goals (however lofty), and to foster discussion that will hopefully nudge to this whole cloud thing forward to the point where the government can start saving money with it. Nonetheless, the challenges that the authors face in trying to help “the cloud” are fundamental, and they’re rooted in the fact that it’s not really clear what, if anything, “the cloud” is.

もちろん、NIST が絵に描くモチである、クラウド・コンピューティングの欲しい物リストを、からかうことは容易であるる。 しかし、そのドキュメントの著者たち自身が、運用のために必要なことより、熱望することを書いていることを、よく自覚していることに注目すべきだと思う。 この NIST のプランは、プライオリティを識別し、ゴールを定義し(どんなに高くても構わない)、論議を促進することを目的としている。したがって、この NIST のクラウド・ロードマップを用いることで、政府は初期費用を節約し、さらにはクラウド全体を促進させると、説得するつもりなのだろう。 それにもかかわらず、「彼らのクラウド」が基本であるという発想を、事実に根ざして促進していく試みにおいて、その著者たちが直面する、クラウドとは何かという課題は、どちらかというと明確にされていない。

I’ve talked before about the confusion around definitions of cloud, and I generally think that people should just stop trying to define the term. The NIST publishes its own definition of “cloud computing,” which features in most definitional discussions of the topic. Few people adopt the NIST definition without alteration, and indeed few adopt almost any definition unaltered.

以前のことだが、クラウド定義の周辺に存在する混乱について話したことがあり、また、その用語の定義を止めるべきだという、私の考えを述べたことがある。 NIST が発行した「クラウド・コンピューティング」における自身の定義は、トピックに関する定義のための論議を促進しようとする。しかし、NIST 定義を変更せずに適用する人々は稀であり、また、あらゆる定義を変更せずに適用しようとするケースは、現実的に有り得ないと思われる。

But as much as it would make me happy to never spend another five minutes of my life listening to or reading someone’s attempt to survey the various definitions of “cloud” before offering their own, it’s clear that confusion reigns even among insiders. So the only point at which this definitional is going to stop is when everyone gets tired of it and moves on — there will be no final definition that ends the debate, and the discussion won’t die as a result of technological shifts because the such shifts are what sustain it in the first place.

自身のクラウドを提示してもいない誰かの、用語の関する定義について、聞かされたり読まされたりするのに、私の人生における 5分間を消費しないで済むなら嬉しいと思うだろう。そして、 それと同じような混乱が、NIST の内部を支配しているのも明確である。 したがって、この定義が収束させることが可能な唯一の時点は、誰もが退屈し、また、前へ進もうと思い直すタイミングとなる。 つまり、定義の完了が、その議論を終わらせるようにはならないだろう。そして、テクノロジー・シフトの結果として、この種の議論が終息しないのは、最初からシフトが約束されているからである。

So “the cloud” is a moving target, and nobody can agree on what it means, which is why the NIST’s attempt to first define “cloud computing” and then build a detailed roadmap around that definition will ultimately prove futile. If the people who are building this ever-changing collection of technologies and services called “the cloud” can’t agree on what it is, then how can one agency define that nebulous abstraction and then give an implementation roadmap? It’s not possible.

したがって、「ここで言うクラウド」は移動し続ける目標となる。そして、最初に「クラウド・コンピューティング」を定義した後に、その定義に基づく詳細なロードマップを構築しようとする NIST の試みが、最終的に徒労に終わると分かっているのに、いったい誰が同意するというのだろうか。この、絶え間なく変化し続ける、「クラウド」というテクノロジとサービスのコレクションを構築しようとする人々は、それが何であるかという点に対して合意に達することができない。そうだとしたら、政府機関の 1つが、この不明瞭な抽象概念を定義した後に、実装のためのロードマップを提供することは、現実的な話といえるのだろうか? それは、有り得ないだろう。

An alternative approach: scrap “the cloud”

I’d like to humbly suggest that if NIST really wants to help government agencies save money, it should get out ahead of the private sector and do what all of us will eventually do one day, which is completely scrap “the cloud” as an useful abstraction.

私が謙虚に提案したいことは、行政機関における IT 支出を、NIST が本当に削減したいと考えるなら、民間部門に先行して前進すべきである。そして、誰もが実施することになる事柄を、極論するなら 1日で完了して欲しい。 つまり、有用な抽象概念としての「ここで言うクラウド」を、完全にスクラップにして欲しいのだ。

imageInstead of framing a discussion of the proper allocation of scarce government IT resources around some notion of “cloud,” NIST should focus first on the kinds of things that users want to do with computers i.e., e-mail, telephony, archival storage, data distribution, publication, content creation, content management, etc. Then, for each application type, the agency should use an agreed-upon set of metrics to evaluate the full range of options that modern computing supplies, from old-fashioned shrink-wrapped software to apps to client-server to SaaS to roll-your-own using PaaS or IaaS.

NIST は、いくつかの「クラウド」概念の周辺で不足している、政府の IT リソースを適切に割り振るために、そのディスカッションに枠にはめるのではなく、ユーザーがコンピュータを用いて処理したい事柄から、最初はフォーカスしていくべきだ。具体的には、電子メール/テレフォニー/アーカイブ・ストレージ/分散データ/パブリッシング/コンテント作成/コンテント管理などである。 続いて NIST は、最新のコンピューティングが供給する、フル・レンジの選択肢を評価するために、すでに合意されている基準のセットを、それぞれのアプリケーション・タイプに適用すべきだ。それらの選択肢には、クライアント・サーバーのための、シュリンクラップされた従来型のアプリケーション・ソフトウェアから、 PaaS や IaaS 上に構築される、SaaS を用いたユーザー・ロールまでが含まれる。

So instead of asking, “what’s this cloud thing and how are we supposed to think about it and take advantage of it?” CIOs would ask, “how are we doing e-mail this year? Are we still storing it locally for compliance reasons, or is Google Apps now approved for agency use? And what’s currently my cheapest option for publishing new regulations internally and taking feedback? Are we putting stuff up on Slideshare.net and embedding it in a blog with comments enabled, or has some other agency rolled their wiki-based own solution that I can then re-purpose?”

そして更に、CIO たちは「 クラウドとは何であり、また、そのアドバンテージについて、どのように活用すべきか?」と尋ねるのではなく、 「電子メールについて、今年はどうすべきか? コンプライアンスのために、ローカルにストアすべきか? Google Apps は 政府機関で使用できるものとして承認されているのか?   そして、組織内に新しい規則を通達して、そのフィードバックをえるための、最も安価な選択枝は? 資料を Slideshare.net に置き、それをブログにエンベッドして、コメントを加えるようにすべきなのか? あるいは、別の政府機関が実現している、wiki ベースのソリューションを再利用すべきなのか?」と尋ねるべきである。

The great thing about this approach is that NIST could reuse much of its existing cloud work to get started. Most, if not all, of the agency’s 10 “cloud” requirements could be re-framed as general software requirements and used to evaluate the best way to deliver a domain-specific compute experience for government end users. So a future NIST report might identify, say, 20 things that people want to do with their computers and mobile devices, so that a subsequent set of 20 reports (putting these in a wiki would be great) could deal with each thing as its own entity.

上記のアプローチの良さは、これまで NIST が作業してきた、クラウドに関する作業の結果を再利用することで、スタートを切れる点にある。この政府機関における 10個の「クラウド」要件の、すべてとは言えなくても、その大半を、汎用的なソフトウェア要件として再構成できる。そして、政府機関とエンドユーザーのドメインに特化された、コンピューティング・エクスペリエンスの供給における、最も適切な方式を評価するために活用できる。 したがって、たとえば NIST からの将来のレポートは、コンピュータとモバイル・デバイスを用いる人々が望む、20 の事柄を識別するようになるかもしれない。それにより、次に提供される 20本のレポート・セットは(wiki に入れば更に素晴らしい)、自身のエンティティとして、個々の事象を掘り下げるものになるかもしれない。

I for one would actually love to read the definitive NIST wiki on government e-mail, or content management, or text-based chat, or off-site backup, or publishing, and so on. Such a living repository of up-to-date evaluations of actual, real-world solutions would be a great resource for the private sector, as well.

私個人としては、政府の電子メール/コンテント・マネージメント/テキスト・ベース・チャット/オフサイト・バックアップ/パブリッシングなどに関する、最終的な NIST wiki を喜んで読むようになるだろう。 このような、現実と実世界を見据えたソリューションを、up-to-date に評価するライブ・リポジトリは、民間部門のための重要なリソースにもなるだろう。

ーーーーー

TAG index今年は、NIST のドキュメントを訳しながら勉強するという時間を、けっこう取っていまして、以下の Security and Privacy と Architecture の訳が終わり、また、いまは、この記事でも取り上げられている Roadmap に取り組んでいるところです。

DRAFT Guidelines on Security and Privacy Issues in Public Cloud Computing
NIST Cloud Computing Reference Architecture (NIST SP 500-292)
NIST Cloud Computing Standards Roadmap (NIST SP 500-291)

訳す身として考えてみると、やはり、何が何でも定義していこうとするスタンスに見え、また、この 3つのドキュメントだけでも定義が重複するところがあり、ちょっと面倒くさいという思いは隠せません。 ただ、訳してみなければ、何を言っているのかも分かりませんので、頑張っているところです。 その甲斐があってか、この記事で Jon Stokes さんが伝えたいことも良く理解できます。そして、この定義が完了することが無いというのも、本当だと思います。 ーーー__AC Stamp 2

ーーーーー

<関連>

NIST がクラウドのための Roadmap と Architecture を発表
NIST の Cloud Architecture 序文
NIST の Cloud Architecture 概要
NIST の Cloud Architecture – プロバイダとユーザーのスコープ
SaaS/PaaS/IaaS とセキュリティの責任範囲 – NIST

 

%d bloggers like this: