パスワードを忘れた? アカウント作成
12725 story

Microsoftのセキュリティ技術部門VP、Mike Nash@本家 4

ストーリー by kazekiri
読み応え十分 部門より

airhead曰く、"今回は、MicrosoftのSecurity Technology Unit担当バイスプレジデント、Mike Nashへのインタビューです。彼は同社のセキュリティ施策を推進してきた中心人物の一人で、同社のWebcast「Security360(要登録 / 日本語字幕版では登録不要)」でホスト役を務めたりもしています。
時期的にもまず「Vistaでセキュリティ面が具体的にどう変わるのか」が気になるところですが、その他にも、ソフトウェア開発段階での取り組みとその内幕、サードパーティへの働きかけ、平均的ユーザーとマルウェア対策、FOSSに対する見解などが話題に上っています(原文)。

(1)
何が変わった?
by suso

PR部門が原稿を用意する毎度おなじみの回答、要するに、実際のところを隠したり控えめに言ったりするために企業が提供したがるようなものは要りません。Microsoftがセキュリティへの注力を増しており、Vistaが以前のWindowsとは異なったものになるということについて、あなたが断言できるものはありますか? どんな裏づけをお話しいただけますか? 「新チームを編成しXをしている」「変更箇所のレビュープロセスはXまで行われている」というような情報は、この質問に答えるうえで有用なものと思います。それとは別に、MSがVistaを開発する過程であなたが目にした、以前の製品におけるあなたの開発のやりかたとの違いはなんでしょうか?

Nash: 我々はMicrosoftで長きに渡ってセキュリティについての考察を重ねてきました。その始まりは、Windows NTをやろうと決めた90年代初頭にさかのぼるかと思います。我々のセキュリティへの取り組みを、よりいっそう深いところから始まる品質の視点に立つものにするという大きな転換があったのは、2002年、Billが「信頼できるコンピューティング」メモを書いたときのことでした。

これを契機として我々は、顧客にとってセキュリティが重大な問題となっていたことを受けて、セキュリティへの注力を大幅に増強することを決めました。思い起こしていただきたいのですが、我々はCode RedやNimdaで後手に回っており、何か手を打つ必要がありました。.NET Framework 1.0、Visual Studio 2002、ASP .NET、Windows Server 2003に対してはセキュリティプッシュとして始まり、製品開発サイクルの比較的後期にあった各チームと個別に面談し、セキュアなコードを書くことの重要性を彼らに説き、彼らに脅威モデルとコードレビューさせる、などを行いました。

これが、セキュアなコードを書くことの重要性について我々の技術者を教育すること、そして企業文化を変えることとどれだけ関わりがあったかを振り返ると、興味深いものがあります。両方の例を挙げてみましょう。

2年か3年前のことになりますがWindows Media Playerに、著作権フィールドを偽造したメディアコンテント片の送信を攻撃者に許すという脆弱性がありました。著作権をパースするコードの欠陥が原因で、攻撃者がバッファをオーバーランさせてマシン上で任意のコードを実行する可能性があったのです。ここで問題となるのは、Windows Media Playerの開発者はその類の攻撃を想定しておき、防止手段を講じておくべきだったか、というものです。考えてもみてください、我々は彼らに、Windows Media Playerを世界一のメディアプレイヤーとするように書いてもらいたいのです。答えは紛れもなくイエスです! 組織の面倒を見るタイガーチーム[*]を配して我々が出荷する一つ一つの製品のすべてのコードをレビューさせてもいいでしょうが、それでは追いつきません。どれだけセキュリティの専門性を高めても、これで充分ということにはならないでしょう――彼らにしても、よりセキュアにしようとしているコードの詳細を完全に把握することはできず、変更を加えることは何かを壊すことになるかもしれないのです。これは最終レビューには有効ですが、最終レビューというものは道路脇のガードレールのようなものでなければなりません――最後の頼みの綱としては結構ですが、我々に必要なのはより良いドライバーです! ですから我々は全員を鍛え上げたのです。ここで重要なのは、時を重ねるごとに新しいものを学びもするから(より良いツール、新たな脅威の方向性、新たなシナリオ)、トレーニングも継続的に最新のものにしなければならない、ということです。
* 企業などからの依頼を受け、クラッカーが使う攻撃手法を用いてネットワークシステムの欠陥を調査する専門家チームのこと。こうした合意のもとに行われる侵入テストは「倫理的 (ethical) 侵入テスト」などと呼ばれる。

企業文化というのもまた非常に大きな問題です。Microsoftは、技術に、ビジネスに、競争にと、それぞれに並々ならぬ力を注ぐ企業です。数あるグループに対してセキュリティを優先事項のリスト上位に置かせるというのは、Microsoftでは変えるのがこの上なく難しいことだったのです。4年前の私といえば、競争圧力があるとか特定時期に出荷することをパートナーに約束しているとか、そういった理由をつけてセキュリティレビュープロセスを経ることはできないと拒みつづけるチームと頻繁に会談を重ねねばならないのが常でした。現在は、概ね、皆からの理解をもらっています。いまや我々にとって、セキュリティが競争力およびビジネスにおいての優先事項なのは明らかなのです。いまなお例外を求める者からの上申を目にすることはありますが、その数は極めて少なくなっています。4年前からの大きな変化の一つは、私がノーと言った場合に組織上層部から大きなサポートを得られるようになったことです。

2003年のBlasterの経験は重要なものを生み出すこととなりました。セキュリティ開発ライフサイクル (Security Development Lifecycle - SDL) と呼ばれているものです。実際のところSDLは、我々が以前からしていた作業を制度化したものです。思い出していただきたいのですが、BlasterはWindows Server 2003の脆弱性を突いていました――これはセキュリティプッシュを通過した製品でした(Windows XPにも影響していました)。脆弱性がどのように発生したのかについて事後分析を行ったときに判明したのは、コードの品質においてWindows 2000とWindows Server 2003の間に大きな飛躍があるにもかかわらず我々にはまだやるべきことがある、ということでした。特に、1) 文書化され反復可能なプロセス 2) 製品リリースプロセスに関与する全員が何をすべきかを理解しているようにするための社内教育 3) このプロセスを継続的なものとするためのリリースプロセス中のチェックポイント、これらを整備する必要がありました。

SDLにおいて鍵となるのは、基本的に6ヶ月毎に更新していく必要がある、ということです。これは、脅威の情勢は変わり、我々がサポートするシナリオは拡大し、我々もさらに学ぶという理由によるものです。

Windows Vistaを素晴らしいものとするために鍵となるのは、最新のSDL――さらなるトレーニング、より新しいツール、脅威モデリング、ファイルパーサに関するより包括的なレビュー、禁じられている(危険な)APIの使用を特定して除去するためのコードのレビュー、そして数多くの侵入テスト――これらすべてを最大限の厳格さをもって実施することです。

この一環として、デフォルト設定をより安全でセキュアなものとする変更についても多くの作業が行われています。通常ユーザーにとってシステムが問題なく動作するように(そのことによって誰もが管理者ユーザーとならなくてもいいように)多くの作業を行っていますが、管理者としてシステムにログオンする必要が依然としてあるユーザー、またはそうしたいユーザーを考慮して、彼らが管理者権限を必要とすることをしようとした場合にもそのことが明確にわかるようにしています。ユーザーはシステムを設定しておくことで、システムがユーザーを昇格させる場面での、昇格を望んでいるかの確認、もしくはパスワードの要求、このどちらも行わせることができます。またVistaのシステムサービスすべてについて、どれが管理者権限を持っているかを調べ、どれが本当に必要としているかを検証しており、必要でないものについては剥奪しています。

Windows Vistaのために我々はエンジニアリングプロセスを強化し、エンジニアリングサイクルにいくつかの新しいチェックポイントを設けました。そういったチェックポイントの一つはVistaのシステムサービスを開発するチームに、新たなVista最小権限オペレーショナルモデルを使用するというプロセスを要求します。各サービスのための計画については社内専門家チームの承認を受けねばなりませんし、代替のアプローチが可能な場面で開発チームがサービスそのものの作成を回避したというのは、かなりの件数に上ります。

セキュリティと安全を向上させるうえでの重要なアプローチとして品質が挙げられるとはいえ、それはその一部分にすぎません。Windows Vistaをさらにセキュアで安全なものとするために、我々はいくつかの重要な機能を加えてもいます。例えば我々は、GIANT Company Softwareから獲得した対スパイウェア技術を採用して改良し、Windows Defenderとしてオペレーティングシステムに統合しました。この対マルウェア技術はWindows 2000およびWindows XPの正規ユーザーにも提供されますが、Vistaに対しての統合は非常に円滑なものになり、顧客にとって保護を受けるのはかなり容易になります。Vistaについて、我々はオペレーティングシステムに組み込まれるファイアウォールの改良も行っています。これは双方向性のもので、IPSecとも上手く機能するよう設計されています。

変化を続けるインターネットでの情勢、そして継続してWindowsプラットフォームに向けられる照準を考えると、残念ながら今後もWindows Vistaを標的とする脆弱性や攻撃が存在するものと思います。これからも怠ることなく、Windows Vistaの脆弱性をよりいっそう見つけにくく、攻撃しにくくしていくことが、1) Windows Vistaにおいて脆弱性および攻撃の両方の数と深刻度は下降し、セキュリティのみを判断基準とするならばVistaへの移行は避けられないものとなる 2) Windows Vista後に登場する製品をさらに良いものにするべく、Windows Vistaの出荷後もセキュリティへの注力を継続する、この2つに繋がるものと確信しています。

(2)
セキュリティ/ユーザーフレンドリーのトレードオフ
by qwijibo

Microsoftにおいて、製品チームがセキュリティに関して一貫した決定を下すのを促進するような全体的なポリシーはありますか? しばしば問題になっていますが、決定の内容をもっとセキュアにすべきということもあれば、もっとユーザーフレンドリーにすべきということもあります。

例えば、ファイルとプリンタの共有のデフォルト値をオフにしておくことで、知らず知らずのうちにリソースを共有してしまうことを防げますが、小規模ネットワークを構成したいと考えている技術に明るくないユーザーに対しては、その方法に関する知識を以前のバージョンよりも要求することになります。

Nash: これは古くからある問題で、我々としてもかなり前進してきています。Microsoftにはデフォルトでオンに設定するという長き伝統があったわけですが、その背景としてはユーザーの活用を容易にする、それに我々の目玉機能を誇示する、というものがありました。過去を振り返ると、実際に私も問題の一端を担いでいたことについて認めざるを得ません。1995年、私は製品管理ディレクターとして、Windows NT Server 4.0において我々のウェブサーバInternet Information Server (IIS) をデフォルトでオンにするという決定を下したチームの一員でした。

ここ5~10年の出来事が我々に(少なくとも私に)残した教訓は、オンにすればするほどシステムは表面の攻撃範囲を広げてしまい、それゆえにより脆弱になってしまう、というものです。完全に近い品質を、もしくは攻撃を試みる者がいないことを想定するなら、それでも問題なしの決定といえるかもしれません。しかしそれは無理というものですし、デフォルトで何をオンにするかについて、我々はより厳しく選択することを求められています。

Code Redのケースを考えてみましょう。このワームは、IISのインデックスサーバのISAPIフィルタにおける脆弱性を攻撃するものでした。ここでちょっと、IISのインデックスサーバのISAPIフィルタが何であるかをあなたは知らない、もしくは気にしない、という場合を想像してみてください。そんなケースであろうが、Windows Server 2000 SP3のIndex Serverを止めてもISAPIフィルタはインストールされたまま、ということが判明しています。あなたはインデックスサービスを停止すれば脆弱性は軽減すると思われるかもしれませんが、そうではないと判明しているのです。

ですから我々はCode Redでのあらゆる経験をふまえて、信頼できるコンピューティングイニシアチブ (Trustworthy Computing Initiative - TwC) を発足させました。セキュリティ開発ライフサイクルの原動力たるTwCの重要な原則の一つは、設計からセキュア、デフォルトでセキュア、導入してセキュア(Secure by Design, Secure by Default and Secure in Deployment - SD3とも)の原則です。

デフォルトでセキュアの原則では、ほとんどのユーザーが使っている機能でないかぎりデフォルトでオフにすべき、と謳われています。これに加えて我々がここに至るまでに学んだことは(先ほどのCode Redの例でもわかるとおり)、ユーザーに見える機能を検証するだけではだめで、その根底にあるサービスを検証する必要がある、ということです。カスタマー機能がデフォルトでオフなら(もしくはユーザーがオフにしたら)、それらを支える根底となるコンポーネントについても上位機能がサービスを使っていないときにはオフにすべきです。

しかしご指摘のとおり、これは一筋縄にいくことではありません。デフォルトでオフとするものを増やすなら、ユーザーが使いたいと思ったときに彼らがオンにするのを容易にしておく必要があります。例えば、Windows Server 2003 SP1において我々は、システムで不要なものを止めるときにユーザーが簡単に設定できるよう設計された、セキュリティの構成ウィザード (Security Configuration Wizard) を追加しました。デフォルトでオフとすることの利点は、1) 機能に脆弱性がある場合、デフォルトでオフになっていることで個々のシステムが攻撃から守られる 2) ワームやウイルスは機能がオンになっているとの前提をとれないゆえに問題の脆弱性を通じてそのシステムを広範囲に渡って攻撃できない、つまりはシステムの母集団も守られる、この2つがあります。

ここで言及しておかなければならないのは、我々が常々どの機能をオフにするかについて考えているとはいっても、デフォルトでセキュアの原則はどの機能をオンにするかに関わるものでもある、ということです。この好例がWindows XPのファイアウォールです。2001年にWindows XPを出荷した当初、ファイアウォールは入っていましたが、デフォルトではオフになっていました。なぜか? そのことを伝えた影響力あるユーザーの多くが、既にファイアウォールを備えているし我々のものをオンにしてほしくない、と言っていたからです。我々のファイアウォールがデフォルトでオンになっていることで悪影響が懸念されるアプリが数多くある、とも言っていました。これは自前でファイアウォールを備えている、ユーザーの割合にして少数にとってはよい答えですが、顧客のほとんどにとっては誤りです。結果論になりますが考えてみてください、2001年10月から2004年8月(ファイアウォールをデフォルトでオンにしたWindows XP SP2の出荷時期)までの間にファイアウォールをデフォルトでオンにしていたら、SlammerやBlasterの問題はWindows XPの顧客に対してはあれほどの広がりにならなかったかもしれません。これはZotobに関しても当てはまります。余談ですが、サードパーティのファイアウォールを備えている顧客、あるいはサードパーティのファイアウォールをインストールするOEM、これらについては我々のものをオフにしても一向にかまいません。

Windows XP SP2で初登場したセキュリティセンター (Windows Security Center) は、適したセキュリティ機能がオンになっていること、適切に設定されていることをエンドユーザーが容易に検証できるよう設計されています。我々はこれをWindows Vistaにおいてさらに良いものする予定です。

これは(安全とセキュリティを第一の仕事とするという目標を皆に意識づける)企業文化に深くまつわるものであるのと同時に、それと同じくらい、(機能のデフォルト状態については必ず、大部分の人が必要とするのは何かという背景のもとに検討されるようにする)プロセスにまつわるものでもあるのです。

(3)
2006年のセキュリティ最優先事項
by Anonymous Coward

ITマネージャの関心において最近ではセキュリティが主要な話題となっており、出版物によっては事実上、一面記事がセキュリティの欠陥やパッチで占められているような状況ですが、あなた自身および業界全体にとって、2006年は何がセキュリティの主な焦点になるとお思いでしょうか?

Nash: 私、そしてMicrosoftにとっての答えはシンプルです。2006年のセキュリティの主な焦点は、Windows VistaとWindows Longhorn Serverにおけるセキュリティ品質と機能を、確実にモノにすることです。誤解しないでいただきたいのですが、何もこれは以前の製品やWindows以外の製品のセキュリティに注意を払わないという意味ではなく、Windows VistaおよびWindows Longhorn ServerはWindowsのリリースとしては過去5年程の中でも最も重大なものになることから判断して、しばらく間は数多くのユーザーに幅広く使われるものとなると認識しているのです――ですから、きちんと決着をつけることは重要なのです。

上に書いたようにいま我々は、セキュアな設計、脅威モデル、コード品質、デフォルト設定、侵入テストといったものにおいてのベストプラクティス、さらには過去に類を見ない厳格さを適用すべき時にいます。システムをより安全でよりセキュアにするために、双方向ファイアウォールやWindows Defenderといった新機能の追加も行っています。我々はプロジェクトが機能の完成に近づく間にも、システムがセキュアであることを検証し、テストで見つかった問題の解決に取り組まねばなりません。

ここには業界に関しての難作業もあります。このうちいくつかは、アプリケーションやセキュリティ製品がWindows Vistaで動くのを確認しつつ行わねばなりません。新しいアプリケーションは、通常の(管理者でない)ユーザーアカウントを持つユーザーの元できちんと動作する必要があります。同時に、セキュリティ製品がWindows Vistaできちんと動作するのを確認しておく必要があるのです。例えば、Windows Vistaできちんと動作する優れた対ウイルスソフトウェアがないとなれば、誰もWindows Vistaに移行しようとはしないでしょう。

業界に関しての私のもうひとつの目標は、サードパーティのアプリケーションや組織内で開発されるアプリケーションが我々のセキュリティ開発ライフサイクルを採用することです。理由はこうです――我々がWindowsの品質を高めるにしたがって、その脆弱性を見つけにくく、それによって攻撃を書きにくくすることになります。結果として、セキュリティ研究者や攻撃の作者はスタックの上層に移るという当然の傾向を見せるでしょう。これはすでに確認されています。我々が学んだように、ここで機能する唯一のアプローチは、広範な教育によってもたらされ説明責任を果たすため出荷に先立って検証される、入念に定義されたプロセスに始まるのです。ここで朗報ともいえるのは、我々が自身のプロセスを非常に明確に文書化して学びやすいものにしている、ということです。これについて詳しくはMSDN Security Developer Center日本語ページ)をご覧ください。

顧客にとっての最優先事項は間違いなく、自らのセキュリティプランを策定し施行することでしょう。私は顧客とともに非常に多くの時間を過ごしていますが、彼らの多くは自らの環境における脅威の分析を行い、セキュリティプランを作り上げていました。とはいえ意外な数の顧客が、プランはあるが施行する機会を逃しているというのです。なによりなことに、大半はセキュリティプランを施行しています――ですから彼らにとっての第一の目標は、自らの環境を見直して新しい脅威に確実に対応できるようにすることです。我々は、顧客(開発者、IT管理者、エンドユーザー)が我々のプラットフォームにおいてさらにセキュアとなるために役立つ、優れた一連のツールの作成も行っています。

我々は顧客がWindows Vistaを評価対象とすることを望んでいますが、いまだWindows XP SP2を導入していない顧客、特に企業顧客がその導入を真剣に検討することは、とりわけ重要です。企業顧客の多数がWindows XP SP2を導入している一方で、まだしていないという顧客も多い。今後Windows VistaまでにすべてのデスクトップがWindows XP SP2にアップグレードするわけではないと理解してはいますが、ラップトップおよびインターネットに直接接続するデスクトップをSP2にすることは、きわめて重要だと考えています。

(4)
セキュリティにおける外からの影響
by kalpol

Linuxのようなオープンソースソフトウェアは、Windowにおけるセキュリティについてのあなたの考え方に影響を及ぼしたか? であれば、どのように?

Nash: オープンソースのアプローチは私のセキュリティに対する考え方に影響を及ぼしましたが、それはあなたが予想するようなものではないかもしれません。2002年後半にいくつかあった反Microsoft PRを導く前提として、目が多いほどソフトウェアはセキュアになるという論がありましたが、それは私のチームや私自身の反応を引き出すものとなりました。私はその第一歩として、私が見逃しているものを見極めようとオープンソースのプロセスを調査し理解することから始めました。

私はいくつかのことを学びました。学んだことの1つめは、多数の人にコードを調べさせると時に問題点を見つけるが、問題を完了するのに良いプロセスを取らなくても咎める者はいない、ということです。私はLinuxコードのレビューについて書かれているLinuxのウェブサイトをいくつか時間をかけて読みました。驚かされたのは、1) ソフトウェアのレビュー方法における一貫性の欠如、2) それらが実際に解決されたことを検証する説明責任の欠如、この2つです。10ヵ月経って2003年、Blasterに見舞われて私は、Linux同様に我々も完了のあいまいさから不利益を被る可能性がある、と実感しました。これを受けて我々はセキュア開発ライフサイクルを作り上げ、その重要項目として、一貫性と説明責任を推進することを挙げたのです。その背景にあったのは、こういう話です…

Blaster発生後に私は、悪用されたバッファオーバーフローについての責任を問うべき者を割り出し、その者の説明責任を確保したいと考えました。しかし詳しく調べてみると、失敗の回避につながるように開発者が従うことになっている文書化されたプロセスもなければ、個々のセキュア開発プロセスが活用されているかを検証するような開発者を対象とした一連の手続きもない、と判明したのです。セキュリティ開発ライフサイクルは基本的に、まさにそれらの、文書化され反復可能なプロセス、明確な教育、そして説明責任を制度化したものです。ここで学んだのは、我々にはマネジメントのすべてのレベルにおいてプロセスを制定し拡充する能力があるのだから、オープンソースのアプローチに模倣できないことを我々のソフトウェアに対して行う機会があったのだ、ということです。

セキュリティに関してオープンソースのアプローチから学んだことの2つめは、有用性 (serviceability) についてです。オープンソースアプローチの支持者が常に挙げることの一つに、オープンソースでは公式パッチを待つ必要がない、コードをダウンロードしてリコンパイルして自ら修正できるから、というものがあります。それはほとんどのユーザーには到底できないことでしょうし、幅広く有効であるとは思えません。うまく自前のパッチを作ることのできる顧客にしても、次のような問題があります。ディストリビューションが新しい修正でコンポーネントを更新するようなことがあっても、比較的精通しているユーザーがすでに自前で済ませているかもしれない修正がそこに含まれているとは限らない。これでは実質的に、自家製パッチを取り消すことになってしまいます。

私が学んだ事柄で鍵となるのは4つ挙げられます。第1、我々の更新がサポートされる全バージョンおよびサポートされる全言語に同時に用意されることは、きわめて重要である。第2、脆弱性が公に開示されるときに我々の更新が用意されているのを確実とするために、できる限りの事をする必要がある。更新を発行するときの謝辞と引き換えに問題を我々に内密に報告することもできるわけで、信頼できる開示は我々にとって大きな助けになります。第3、更新を発行するときには品質の高いものにしなければならない。我々の更新が問題を起こせば更新への信頼が揺らいでしまいます。我々の製品を私が定義づけるとしたら、我々が出荷する製品プラス最新のサービスパックプラス最新のサービスパック後に我々が出荷するあらゆるセキュリティ更新、となります。もし我々がセキュリティ更新を幅広いシナリオでテストしなければ、何らかの問題を起こす可能性は大いにあるのです。

最後に(第4)、更新の導入プロセスを簡略化するツールを用意することは重要である。これによって更新を導入する際の障害を減らし、顧客が最新の状態にあることの公算を引き上げることになるからです。我々がWindows Update、Microsoft Update、Windows Server Update Services、Systems Management Serverのような、パッチ導入を大幅に分かりやすいものにするツールに注力してきた理由は、ここにあるのです。

(5)
Microsoftセキュリティの基本的アプローチとは?
by kickabear

悪用されうるバグを避ける方法としてMicrosoftは、厳格に施行されるコーディング規則をより重んじる傾向にあるのだろうか、それとも、テスト期間におけるしらみつぶしのバグ検出をより重視しているのだろうか?

簡単に答えるなら「もちろん両方」となるだろうが、50/50に割れるというのは考えにくい。で、テストが後部座席にまわるのか、それともコードが?

Nash: 手短に答えるなら実際のところ、3つめの選択肢、つまりはより良い設計になります。これは、ある機能がシステムに持ち込むかもしれないセキュリティ脅威をきちんと理解すること、そして機能やコンポーネントの設計がリスクを低減するのを確実にしておくこと、これらから始まります。しかる後に我々は実装に移りますがその一部分として、あなたの言われる通り、より良い規則も関わってきます。これは教育を通じて伝えられねばならないものですが、コード品質を検証するツールでの補強は可能な限り行われねばなりません。

我々は倫理的に行われる侵入テストおよびインターフェイステストについても、それぞれ多くの時間をかけて行っています。バグの検出は重要ですが、それはあくまで最後の頼みの綱です――ある意味、ソフトウェアエンジニアリングという道路を安全にドライブするための道路のガードレールなのです。悪条件の道路で運転することと同じく、安全はドライバーへの(この場合開発者への)より良い講習から始まるのです。

とはいうものの、この仕事をしていて過去5年間に学んだものを一つだけ挙げるとすれば、セキュリティに銀の弾丸はない、これに尽きます。我々はそれに替わって、数々の投資を通じて前進をしているのです。

(6)
なぜDRMを加える? また、なぜIEを分離しない?
by Bob_Villa

なぜ君らはVistaに、標準的ユーザーが欲しがりそうにないDRMコントロールを加えようとしているんだ? 自社ドキュメントをコントロールしたい企業にとっては便利かもしれないが、自身のドキュメントやファイルを制限する製品と知りながらも欲しがる標準的ユーザーがどれだけいるか、私には疑問だ。

それと、WindowsからInternet Explorerを分離することでセキュリティを劇的に改善できるんじゃないかと思う。Opera、FireFox、Safariなどと同様、別個のプログラムだったら… Windows ExplorerがInternet Explorerで動いていることに、正当な理由なんてあるのだろうか?

Nash: まず最初に、一点だけ確認しておきましょう。この場合、あなたがいっているのは現在Windows Vistaに統合されているRights Management Services (RMS) クライアントを指しているのであって、以前からWindowsに組み込まれていてメディアコンテントを保護するのに使われているDRM技術ではない、と思います。RMSの場合で話を進めますが、おっしゃる通り、企業は自らの情報を保護すること、情報の使用をコントロールすることに価値を見出しています。RMSの現行バージョンを使っている顧客からのフィードバックの重要なものとしてセットアップが難しいというのがあったので、我々はRMSクライアントをWindows Vistaに統合したのです。とはいっても、顧客によってはそれを使わないかもしれません。OfficeのようなRMSを利用するアプリケーションがインストールされていて、Officeのその機能を使うとユーザーが選択した場合に限って、使われることになるでしょう。

また我々は、いずれ標準的ユーザーも自身の情報を保護したいと思うようになる、とも考えています。例えば将来ホームユーザーも、友人のリスト、写真、銀行口座情報、その他の個人データといった情報の使用を保護しコントロールしたいと思うかもしれません。

Internet Explorerにまつわる質問については、現実的には2つの側面があります。1) WindowsにIEを備えることの背景にあるプラットフォームの密接な関係、および、2) WindowsにIEを備えることで可能となるユーザー体験、です

プラットフォームの視点からいえば、IEの分離は多くのものを後退させるでしょう。HTMLのレンダリングやインターネットへのアクセスをIEに依存しているアプリケーションは数多くあります。考えてみてください、電子メールアプリケーション、AOL Explorerのようなインターネットを扱えるクライアント、あるいはMicrosoft Moneyでも結構です。これもアプリケーション内でHTMLを描画するのにIEを使っているのです。IE分離は多くのアプリケーションを後退させるだけでなく、そのことによって自前のHTMLレンダリング機能を書かねばならなくなる開発者の、大きな負担にもつながるのです。

体験の視点からいえば、かねてからのWindowsの重要な目標の一つに、ローカルの体験とリモートの(インターネットの)の体験をユーザーインターフェイスの観点から統合することがあります。オペレーティングシステムへのウェブブラウザの統合は、この体験を顧客に届けるうえで重要な部分を占めていたのです。我々にもっとうまくやれる分野といえば、リモートサイトによってやれるような類のものはローカルでやれることよりも少なくする、これを徹底することです――これは見知らぬサイト、信用していないサイトに関しては、何を差し置いても当てはまることです。Windows Vistaに向けたIEの重要な強化の一つに、保護モードなどと呼ばれているものがあります。IEは当初、システムとユーザーリソースへのアクセスを最小限しか持っていない状態です。例えば、いずれかのリモートサイトにアクセスしても、サイトはソフトウェアをインストールしたり、ユーザーのスタートアップフォルダにファイルをコピーしたり、IEのホームページや検索プロバイダの設定を乗っ取ったりするだけの権限を持ち合わせません。もちろん、ユーザーが他のブラウザを使うことと選んでもまったく問題はありませんし、他のブラウザをマシンのデフォルトに設定することも可能です。

我々がWindows VistaのIEにおいて行っている前進によって、現在皆さんがIEのセキュリティに抱いている懸念の多くが対処されるものと、私は確信しています。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
typodupeerror

Stay hungry, Stay foolish. -- Steven Paul Jobs

読み込み中...