June 2008 June 2008
セキュリティ: 大論争 : 隠すことによるセキュリティ
隠すことによるセキュリティとは、攻撃を受ける可能性のある部分を取り除くのではなく、その部分を隠す対策を実装することを指します。これが悪しき慣習だと主張する人もいれば、大規模な戦略の一部として役立つと主張する人もいます。この議論は非常に白熱し、知識が豊富なマイクロソフトの専門家の間でも対立が起こっています。この記事では、隠すことによるセキュリティについて説明した後、この議論の 2 つの立場について説明します。 Jesper M. Johansson and Roger Grimes
セキュリティ: Windows Vista 用の新しい昇格 PowerToy
Michael Murgolo が、"昇格 PowerToy" の更新版と共に戻ってきました。サードパーティ製のスクリプト ツールと連動する、強化された "管理者として実行" 機能、この機能を Windows Vista で廃止された便利な Windows XP の機能の代わりに使用する方法、および多くの便利なツールを紹介します。 Michael Murgolo
セキュリティ: BitLocker ドライブ暗号化の強化点
Windows Vista SP1 と Windows Server 2008 では、データ ボリュームのサポートや暗号化攻撃に対する保護の強化など、BitLocker の重要な変更点が導入されています。この記事では、Byron Hynes が、これらの新機能の概要と、サーバー上で BitLocker を使用する方法について説明します。また、BitLocker に影響する最近の一部の報道についても取り上げます。 Byron Hynes
セキュリティ: ソフトウェア制限ポリシーを使用したアプリケーションのロックダウン
社内にあるデスクトップ コンピュータの総保有コストを削減する必要がある場合、アプリケーションのロックダウンを利用すると、サポートされていないアプリケーションに関連する IT の問題を制限できるため、非常に役立つ可能性があります。ここでは、ソフトウェア制限ポリシーとグループ ポリシーを使用して、IT インフラストラクチャ全体で実行されるアプリケーションを制御する方法について説明します。 Chris Corio and Durga Prasad Sayana
セキュリティ: Windows Vista のファイアウォールを管理する
Windows Vista のファイアウォールは、最近の更新においていくつかのすばらしい新機能が追加され、企業環境向けのファイアウォールとして魅力的な選択肢となっています。この記事では、Jesper Johansson が Windows ファイアウォールの進化について概説し、管理者の理解の助けとなるよう、新しい規則とプロファイル、ドメインの分離、暗号化などの機能強化について詳しく説明します。 Jesper M. Johansson
セキュリティ: デジタル証明書を使用して電子メールをセキュリティで保護する
Secure Multi-Purpose Internet Mail Extensions を使用すると、送信中の情報を隠して、送信者を確認し、メッセージを認証することができます。この記事では、デジタル証明書を使用して電子メールをセキュリティで保護する方法と、S/MIME システムで発生した問題をトラブルシューティングする方法を紹介します。 Matt Clapham and Blake Hutchinson
Columns
編集長から: 大論争: | レター: 読者の皆さんからの声: | ツールボックス: IT プロフェッショナル向けの新製品:
SQL に関する Q&A: I/O エラー、データベース ミラーリングなど: Paul Randal が SQL Server に関する質問に回答し、テスト データベース内に破損箇所を作成する方法、圧縮と拡張を繰り返すサイクルを回避する方法、およびどれぐらいの数のデータベースをミラーリングするとパフォーマンスが低下し始めるかを確認する方法について説明します。Paul S. Randal | ユーティリティ スポットライト: Windows Vista Upgrade Advisor: 組織のシステムを Windows Vista にアップグレードする準備は整いましたか? お使いのシステムで Windows Vista を実行することが可能かどうか、また、どのバージョンに対応しているかを判断する際に Windows Vista Upgrade Advisor がどのような働きをするかについて説明します。Lance Whitney | SharePoint の内部: サイトの管理を分散する: SharePoint インフラストラクチャに対する一元的な管理者レベルの制御を維持しながら SharePoint サイトに対する管理者レベルの制御を個々の部門に委任することによるメリットと影響について説明します。Pav Cherny
Windows PowerShell: 見栄えの良い出力: Windows PowerShell のオブジェクト指向の性質によって、書式設定がどのように出力に適用されるかについて説明します。Don Jones | Hey, Scripting Guy!: それほどコツコツ働かなくても報われる: 今月の Scripting Guys は、コツコツ働くこと、真の幸せ、そして読みやすい表形式でコマンド ウィンドウにデータを出力することについてじっくりと考察します。The Microsoft Scripting Guys | デスクトップ ファイル: セキュリティと規制遵守: IT プロフェッショナルは、相反する 2 つの目標に対処しなければならない状況によく陥ります。この記事では、セキュリティが規制遵守の犠牲になることがどれほど多いかについて説明します。Wes Miller
ビジネスにおける IT: 環境リーダーになるための 10 のポイント: 環境に関する企業の取り組みにおいて IT 部門がますます重要な役割を果たすようになり、IT プロフェッショナルは、企業内と業界内で変化を推進し、思想リーダーとなる機会を得ています。この記事では、組織が環境と持続可能性に関する取り組みを推進するうえで、思想リーダーとして効果的な役割を果たすためのポイントについて説明します。Michael Walsh and Eliza Walsh | フィールド ノート: 分割画面を共有する: Microsoft Research India で開発された分割画面を使用すると、2 人のユーザーが 1 台のモニタを共有して、それぞれ独立した OS のインスタンスを実行することができます。Kentaro Toyama | Windows 秘話: 最も悪名高い 2 つの PC 機種: Raymond Chen が、最も悪名高い 2 つのコンピュータ機種を使用した思い出を語ります。Raymond Chen


セキュリティ
大論争 : 隠すことによるセキュリティ
Jesper M. Johansson and Roger Grimes
概要:
  • 隠すことによるセキュリティを定義する
  • 隠すことによるセキュリティ対策を評価する
  • Administrator アカウント名を変更することの価値を判断する
  • 十分な情報に基づいてリスクを考慮した決定を下す

"隠すことによるセキュリティ" という言葉は、セキュリティに詳しい人、特に自らを専門家と考える人からは、よくひんしゅくを買います。一部の集団の間ではほぼ禁句と見なされている、
この隠すことによるセキュリティは、Wikipedia の説明 (en.wikipedia.org/wiki/Security_through_obscurity 参照) にもあるように、非常に意見が分かれるセキュリティの 1 つの側面を表しています。今後、この対策を実装している人の努力を "所詮は隠すことによるセキュリティ" と笑い物にする文章をよく目にすると思います。
簡単に言うと、隠すことによるセキュリティは、ケルクホフスの原理に反しています。この原理は、システムはその設計自体がセキュリティで保護されている必要があり、敵対者に設計が知られていないからセキュリティで保護されていると考えるべきではないというものです。ケルクホフスの原理は、基本的に "秘密はそう長い間秘密ではいられない" ことを前提としています。
これを示す非常に良い例があります。Windows NT® LAN Manager (NTLM) 認証プロトコルの設計は、最初のうちは非公開であると考えられていました。UNIX オペレーティング システム向けの相互運用製品である Samba を実装するために、Samba チームはこのプロトコルをリバース エンジニアリングする必要がありました。その結果、NTLM に関する最も包括的なドキュメント (monyo.com/technical/samba/translation/ntlm.en.html) が作成されると同時に、多くのバグが発見されました。セキュリティの大部分が暗号化によって形造られたこと、および非常に多くの非公開設計の詳細が明らかになっていることから、多くのセキュリティ専門家は、あらゆる情報セキュリティがケルクホフスの原理に従っていると考えています。
ですが、隠すことによるセキュリティは常に悪なのでしょうか。この記事では、隠すことによるセキュリティについて説明し、なぜ多くの人がこの対策を時間の無駄 (またはその逆) と考えるのか、およびなぜこの議論の答えが、例によって最初に思ったよりも複雑になるのかを解明するための手掛かりを提供します。

隠すことによるセキュリティの概要
既定の設定を変更しない (Steve Riley)
私は名前の変更に関しては、"変更しない" 側を支持します。実際には、これはセキュリティの問題ですらなく、システム管理の問題です。また、私はシステム管理について、以前よりも長い時間考えるようになったので (管理とセキュリティが同じカテゴリで扱われるようになったからです)、システムの脆弱性が高まる可能性のある操作は一切行わないという考えを以前よりも支持するようになりました。既定の設定を変更すれば、脆弱性が高まることは目に見えています。人々が既定の設定を変更する理由は 2 つ (いや、3 つですね) あります。
  • 変更によって機能の要件が満たされることがわかっている。
  • 変更によってセキュリティが強化されることを想定している。
  • (注意 : これは良識を疑うような理由です) だれかが雑誌の記事で読んだと言っていた。
1 つ目の理由で既定の名前を変更する必要がある場合は、変更して問題ありません。多くの場合、このような変更はテストを経て実装されるので、システムが不安定になることはほとんどありません。
2 つ目の理由で既定の名前を変更する場合は、少し立ち止まって考え直してみてください。このような変更は、ソフトウェアの製造元によってほぼまったくテストされていないので、その製造元も変更後のシステムの動作を予測できません。さらに通常は、真のセキュリティを提供する、より優れた方法が他に存在します。
悪意のある人物に偶然アカウント名が知られても、どうということはありません。パスワードの力によって、システムはその人物から保護されます。Administrator や Guest などの既定のアカウント名を、簡単に推測できない名前に変更するよう促される場合は、強力なパスワードやパスフレーズを使用したくないという願望が込められていることがほとんどです。本当の問題 (秘密が漏れやすいこと) を解決すれば、(既定の名前の変更による) 脆弱性を回避できます。

隠すことによるセキュリティには、問題がまったく緩和されない対策は含まれていません。たとえば、組織のネットワークの境界に設置されているルーターで、ネットワーク ニュース転送プロトコル (NNTP) をブロックして、従業員がニュースグループを購読しないようにしても、Secure Shell (SSH) の送信接続が許可されていれば、隠すことによるセキュリティが実装されているとは言えません。SSH はすべてのプロトコルをトンネルできるので、問題となる部分は隠されません。この効果の低い緩和策のメリットは、正当なユーザーがセキュリティ ポリシーに違反することなく正当なタスクを実行できることのみです。このような対策は、隠すことによるセキュリティではなく、単なる効果の低い無意味な対策です。
"隠すことによるセキュリティ" の "セキュリティ" とは、その対策によってなんらかの保護を受けることができることを示しています。ただし、もう 1 つのメッセージが含まれており (これが問題なのですが)、実際には、攻撃を受ける可能性がある部分を取り除くわけではありません (基本的に、攻撃者は、この部分を糸口にしてシステムにアクセスします)。
たとえば、脆弱性のある Web サーバーを所有しているとします。公になっているバグを突破口にし、TCP ポート 80 を経由すれば、このシステムを攻撃できます。この突破口を塞ぐには、Web サーバーに修正プログラムを適用するか、Web サーバーを停止します。どちらの場合も、このバグを利用した攻撃を完全に回避できます。また、ファイアウォールや IPsec を使用し、選択された一部のコンピュータを除くすべてのコンピュータに対してポート 80 を閉じることによって、部分的に攻撃を回避することもできます。完全に攻撃を回避できるわけではありませんが、問題は大幅に緩和されます。
一方、隠すことによるセキュリティでは、攻撃を受ける可能性がある部分を取り除くのではなく、単にその部分を隠します。たとえば、Web サーバーのポートを 80 から 81 に変更することによって、Web サーバーでポート 81 が使用されていることを知っているユーザーのみが、その Web サーバーにアクセスできるようにする場合があります。ここで議論は終わりません。実際は、Web サーバーのポートを 81 に変更しても、回避できるのは一部の攻撃のみであり、たいていはエンド ユーザーに不便を感じさせるだけです。高い技術を持つ侵入者は、単純にポート スキャナと Web バナー取得ツールを大量のポートに対して実行し、標準以外のポートを使用している Web サーバーを検出します。攻撃を受ける可能性がある部分を取り除いたわけではなく、単に (一時的に) 隠しただけなので、該当するポートを検出すれば、攻撃者はその部分を突いてサーバーを攻撃できます。
これは、隠すことによるセキュリティを試すことすら推奨されないという意味でしょうか。その答えは "ケース バイ ケース" です。情報セキュリティ分野における他のすべてのことがそうであるように、結局はリスク管理が最も重要なのです。考慮すべき重要な要素を理解するために、隠すことによるセキュリティ対策をもう 2、3 種類紹介した後、"Administrator アカウント名を変更する" という対策について詳しく説明します。

セキュリティ対策を評価する
隠すことによるセキュリティの例は数多く存在します。システム管理者やネットワーク管理者が実装するものもあれば、ソフトウェア開発者から始まるものもあります。ただし、どの対策も、脆弱性を潜在的な攻撃者から隠すことによって、その脆弱性を緩和することを目的としています。
これらの対策のうち、まったく良い効果をもたらさないものもあるのでしょうか。隠すことによるセキュリティ対策は、すべて悪だと言い切れるのでしょうか。少なくとも一部の対策を支持する人は確実に存在します。たとえば、Windows® エクスプローラでは、ドライブ文字を隠すことができます。多くの環境 (最も顕著なのは学校のコンピュータ室) では、この手法を利用して、ハード ドライブにデータが保存されないようにしています。もちろん、それでも多くのアプリケーションはハード ドライブにデータを保存できるので、究極的なセキュリティ対策と比較すると、その価値はほとんどありません。ただし、この対策を実装した施設からは、ハード ドライブ上のデータが減少したという声がよく聞かれます。
Windows 上で実装される、隠すことによるセキュリティ対策としてもう 1 つ挙げられるのは、管理用ネットワーク共有 (C$ や Admin$ など) の無効化です。この方法を使用すると、攻撃者がリモートでコンピュータに接続できなくなると考えられていますが、実際には、この意図した効果が得られないだけでなく、管理用共有を使用できるアカウントを持つユーザーは、まったく同じ共有をリモートで再度有効にできます。ただし、多くの組織からは、これらの共有を無効にすることによって、組織のネットワーク上でマルウェアが検出される確率が低下したという報告が寄せられています。
見当違いの対策の例として最も紹介したいのは、Windows の [デバイス : ログオンなしの装着解除を許可する] という設定です。この値を [無効] に設定すると、ログオン画面に [コンピュータの装着解除] ボタンが表示されなくなります。この設定は、攻撃者が簡単にコンピュータを取り外すことができないようにすることを目的としています。もちろん、侵入者は、このボタンが表示されているかどうかにかかわらず、コンピュータとドッキング ステーションの両方をバッグに詰め、それらを持ち去ることができます。したがって、この設定は、惜しくも隠すことによるセキュリティとは言えません。
もう 1 つのわかりやすい例は、[ドメイン コントローラ : サーバー オペレータがタスクのスケジュールを割り当てるのを許可する] という設定です。この設定は、まさにその名前が示すとおり、Server Operators グループに属しているユーザーがタスクのスケジュールを割り当てるのを許可します。この問題には慎重に対処する必要があります。その理由は、このようなタスクがローカル システムとして実行される場合があり、ローカル システムとして実行されるタスクのスケジュールを割り当てることができるのは、管理者のみであるからです。もちろん、サーバー オペレータはさまざまな手段で自らを管理者に昇格させる可能性があるので、実際にはこの設定を使用してサーバー オペレータがタスクのスケジュールを割り当てることができないようにしても、ほとんど効果はありません。
ただし、多くの組織はこの設定を好みます。その理由は、組織のエンジニアに、管理者ではなくサーバー オペレータの役割を与えることによって、それらのエンジニアが誤ってサーバーを破壊する可能性を低下させることができるからです。このこと自体は、いくらかのメリットをもたらす可能性があります。
では、この議論に対してどのような判決を下せばよいでしょうか。言うまでもなく、いくつかの問題は非常に複雑になる可能性があります。私たちは、隠すことによるセキュリティ対策について、充実した議論を交わしました。Roger は、これらの対策を実装することは効果的であるという主張を断固として支持しています。一方 Jesper は、ひいき目で見ても、ほとんどの場合、これらの対策は時間の無駄になると考えています。では、隠すことによるセキュリティの事例として、最も引き合いに出され、論争の的になっている、Administrator アカウント名を変更するという対策について考えてみましょう。Roger はこの対策を支持し、Jesper はそれに反対しています。セキュリティ分野で有名な Aaron Margosis と Steve Riley も、補足記事「Administrator アカウント名を変更する」と「既定の設定を変更しない」で、それぞれこの議論に参加しています。

Administrator アカウントを隠す
Administrator アカウント (相対識別子 (RID) 500) 名を、一般の人に知られていない名前に変更することは、セキュリティ専門家が推奨する対策として挙げられることが多く、マイクロソフトのいくつかのセキュリティ強化ガイドにも記載されています。また、グループ ポリシーには、Administrator アカウント名を変更するための設定が含まれています (図 1 参照)。この対策は、Administrator アカウント名を変更すれば、攻撃者が実際の管理者としてログインするのが困難になるという考え方に基づいています。もちろん、グループ ポリシーを使用してこの操作を行うことには、明らかな問題点があります。それは、Administrator アカウント名を変更すると、そのグループ ポリシー オブジェクトが適用されたすべてのコンピュータに同じ名前が登録されることです。これでは、このセキュリティ対策によって提供されるあいまいさの価値が低下してしまいます。
図 1 Administrator アカウント名の変更
図 1 Administrator アカウント名の変更 (画像を拡大するには、ここをクリックします)
ここで、もう 1 つ重要なことを認識しておく必要があります。それは、正当なアカウントを持つユーザーは、管理者アカウント名が Administrator から変更されているかどうかにかかわらず、その管理者アカウント名を取得できるということです。Administrator アカウントの RID は常に 500 です。アカウントを持つすべてのユーザーは、単純に RID が 500 のアカウントを照会することによって、そのアカウントの実際の名前を確認できます (図 2 参照)。
図 2 Administrator から変更されたアカウント名の確認
図 2 Administrator から変更されたアカウント名の確認 (画像を拡大するには、ここをクリックします)

Roger の見解
Administrator アカウント名を変更することへの反論として私がよく耳にするのは、セキュリティ プリンシパルのアカウント名を、そのアカウントに関連付けられているセキュリティ識別子 (SID) に変換して RID を確認するのは簡単であるという主張です。実際の Administrator アカウントの RID は常に 500 なので、攻撃者がユーザー アカウント名を SID と RID に変換して、簡単に 500 という RID を見つけることができるなら、なぜわざわざ Administrator アカウント名を変更するのでしょうか。
実際はそれほど単純にはいきません。ユーザー アカウント名を SID と RID に変換するには、NetBIOS または LDAP 用のポートにアクセスできる必要があります。ほとんどの境界ファイアウォールでは、インターネットを経由したこのようなアクセスが許可されないので、攻撃者は完全にファイアウォールを回避するまで変換を実行できません。さらに、ドメイン コントローラ (DC) を除く、Windows XP 以降のバージョンがインストールされているコンピュータに対して、匿名で SID 変換を実行することはできません。最も外部にさらされている (危険性の高い) コンピュータに対して、アカウント名から SID への変換を実行するには、認証済みの資格情報を使用する必要があります。
変換攻撃を開始するには、非常に数多く実装されている多層防御の壁を乗り越える必要があります。また、攻撃者がこれらの壁を乗り越えたとしても、最終的にはアカウント名が変更されていない場合と同じ地点にたどり着くことになります。Administrator アカウント名を変更すると、セキュリティを強化でき、これによってシステムが脆弱になることはまずありません。
もう 1 つの秘密 攻撃者が管理者アカウント名を把握していない場合は、そのアカウント名も、パスワードと同様、解き明かす必要がある "秘密" となります。確かに、ユーザー アカウント名が管理者のパスワードと同じくらい複雑である可能性はそれほど高くありませんが、このもう 1 つの障害が存在することによって、パスワードを推測および解読するという課題は飛躍的に複雑になります。パスワードの侵入テストを行ったことがあれば、ユーザー名とパスワードの両方を推測するためにどれほど多くの作業が必要であるかはご存知でしょう。既に困難な作業に、もう 1 つ複雑な作業が追加されることによって、作業はさらに困難になります。
自動化されたマルウェアとスクリプト キディによる攻撃を阻止する 私は Windows のセキュリティ防御に 22 年間携わっており、5 年前から、8 つの Windows ハニーポット (おとりのシステム) を実行し、インターネットに公開しています。この 5 年間で、Administrator (*NIX システムの場合はルート) 以外のユーザー アカウントを使用する、自動化されたマルウェア (このソフトウェアによって攻撃の大半が行われています) が確認されたことは一度もありません。Administrator アカウント名を変更すれば、Administrator という名前に依存するすべてのマルウェアによる攻撃を即座に回避し、セキュリティ リスクを軽減できます。
スクリプト キディについても同じことが言えます。私の知る限り、Windows のハッキングに関する優れたマニュアルには、アカウント名から SID への変換を利用する手法が記載されていますが、どういうわけか、私がスクリプト キディを混乱させるために公開した、"偽の" Administrator アカウントが実装されたハニーポットを攻撃するための手法は見たことがありません。優れたハッカーは、発見した Administrator アカウントが本物の Administrator (RID 500) であるかどうかを必ず検証するはずですが、彼らはこのことを検証していません。理由はわかりませんが、ハッカーが怠けているか、これが人間の一般的な習性なのでしょう。
プロのハッカーによる攻撃もほぼすべて阻止する これを聞いてほとんどの皆さんは驚くと思いますが、数年間ハニーポットを実行していると、自動化された攻撃、スクリプト キディ、およびプロのハッカーの違いがすぐにわかります。過去 5 年間で、私のハニーポットに対する何百万もの攻撃が報告されましたが、偽の Administrator アカウントが実装されたハニーポットに対して SID 変換が行われた例は 1 つもありません。
もちろん何人かの犯罪のプロは SID 変換を企てたと思いますが、おそらくそれもごく一部の少数派です。また、この変換方法は文書化および公開されていません。なぜプロのハッカーがその作業を行わないのでしょうか。おそらく、ハッカーたちは、大半の人が取り組んでいないことに対して努力する理由がわからないのだと思います。
警告を単純化する 対立するもう一方の立場は、Administrator アカウント名を変更することが一般的になれば、その手法はあいまいではなくなり、価値が失われると主張しています。つまり、マルウェア、スクリプト キディ、およびプロのハッカーが今まで取っていた作戦を変更し、単なる Administrator 以外の名前を探すようになるという考え方です。これはもっともな主張です。さいわい、基本的な条件は変わりません。まず、Windows の非常に強い特権を持つアカウントの名前が Administrator ではなくても、悪意のあるハッカーは複雑な作業を行う必要があります。これは事実です。また、悪意のあるハッカーが複雑な作業を行う必要がある場合、実際にハッカーがその作業を行う可能性はほとんどありません。その理由は、補完し合う他のいずれかの多層防御手法によって、その悪意のある行為が検出されやすくなるからです。
このことを根拠に、私が名前の変更に賛成する最後の理由を示します。Administrator アカウント名を変更し、さらにその名前を持つ別のアカウントを作成すると (図 3 参照)、優れた警告メカニズムが提供されます。イベント監査機能によって、既定の名前を使用したログオンの試行が検出されたら、すぐにそのイベントを調べることができます。
図 3 Administrator というおとりのアカウントにログオンさせることで早期に警告を受け取ることができる
図 3 Administrator というおとりのアカウントにログオンさせることで早期に警告を受け取ることができる (画像を拡大するには、ここをクリックします)
イベント ログには、特に意味を持たない "不正な" ログオンが多数記録されます。通常それらは、ユーザー (または Windows) が誤ったパスワードなどを使用してログオンしようとしたことを示しているだけですが、Administrator アカウント名を変更しないとしたら、どのようにして正当なログオンの試行を不正なログオンの試行と区別すればよいのでしょうか。Administrator というログオン アカウントが存在しない状態で、そのアカウント名を使用したログオンの試行が検出された場合、そのログオンはおそらく不正な目的で試行されています。早期に警告を受け取って影響を小さくすることは、今日の防御にとって大きな価値があると言えます。

Jesper の見解
Administrator アカウント名を変更する (Aaron Margosis)
Jesper は、理想としては非常に正しい意見を述べています。それは、ブルート フォース攻撃を使用した推測に耐えられる強力なパスワードを設定し、さらに -500 ローカル管理者アカウントを非常時の回復にのみ使用すればよいという意見です。ただし、実際にはどちらも実現されていません。
Jesper は、セキュリティ関連の普及活動に尽力し、パスフレーズに関するすばらしい連載記事 (「パスフレーズ vs. パスワード」第 1 部 (go.microsoft.com/fwlink/?LinkId=113157)、第 2 部 (go.microsoft.com/fwlink/?LinkId=113159)、第 3 部 (go.microsoft.com/fwlink/?LinkId=113160)) を執筆しましたが、多くのシステム管理者は、強力なパスワードの最新の構成方法を理解していません。
最近まで、パスワードは複数の文字セットからランダムに選択された 8 つの文字で構成されていましたが、ムーアの法則によって、その構成方法は時代遅れになりました。ユーザー (およびシステム管理者) の教育は最も力が注がれていない分野であり、強力なパスワードというトピックがテレビのニュースの話題を独占しない限り、おそらく今後も軽視され続けるでしょう。
現在の世の中では、パスワードの推測に 6,000 億年もの時間は必要なく、多くの場合は昼食の間に完了してしまうので、1,000 倍の時間がかかるようにすることで、真の価値がもたらされる可能性があります。また、Administrator アカウント名を利用しようとする多くの自動化された攻撃は、アカウント名を変更することによって回避できます。
通常、Administrator アカウント名を変更する作業にそれほど多くの時間と手間はかかりません。先ほど述べたとおり、通常は単純な GPO の設定によって実装できるからです。実際、米国政府が規定した Federal Desktop Core Configuration (csrc.nist.gov/fdcc) では、-500 アカウント名の変更が要件として挙げられています。この名前の変更は、要件として挙げられている多くの設定の 1 つに過ぎませんが、他の要件に比べて、それほど多くの時間や注意を必要としません。また、人々がセキュリティの価値に関する誤った認識を持ってしまう場合もあります。いまだに、"管理者アカウント名を変更したから、もう修正プログラムを管理する必要はない" という声を耳にします。
組織全体でアカウント名を同じ名前に変更することは、どれほどの価値をもたらすでしょうか。若干の価値はありますが、その価値は大きくありません。その理由は、Administrator を想定した、自動化された攻撃をブロックできても、新しい名前を知らない人が、一連の潜在的な攻撃者に含まれるからです (組織全体で、ローカル管理者アカウント (名前を変更しているかどうかにかかわらず) に同じパスワードを使用している場合、リスクは高くなります。このようなリスクに対処することは、より大規模で重要な問題です。-500 アカウントを無効にすることも 1 つの方法ですが、これによってドメイン アカウントを使用できない場合の重要な回復手段が失われてしまいます)。もう 1 つ指摘しておきたいのは、マイクロソフトのセキュリティ ガイドでは長い間既定のアカウント名の変更が推奨されているので、この操作は十分にテストされており、サポートも万全であるという点です。
ここまでの説明から、隠すことによるセキュリティ対策が、単独では十分な防御策にならないことがおわかりいただけたと思います。これらの対策は、その他のセキュリティ対策を強化でき、Roger のデータがそのことをはっきりと示しています。組織のセキュリティ対策の実装コストがそれほどかからない場合は、隠すことによるセキュリティをそれらの対策から除外しないことをお勧めします。

Administrator アカウント名の変更に賛成する意見もあれば、この考えに反対する妥当な意見もあります。この話題に入る前に、Roger の最後の主張がきわめて妥当であることを認めておかなければなりません。ただし、厳重に管理されている環境では、回復が必要な非常時にのみ Administrator アカウントが使用されるので、このアカウントを使用したログオンが行われた場合は、その詳細を調査する必要があります。
過剰な対策 Administrator アカウント名を変更することによって、このアカウントのパスワードがリモートで推測される危険性を軽減できます。ただし、Administrator アカウント名の変更によって妨害を受けるのは、他にそのコンピュータの承認済みアカウントを保有していないユーザーのみです。このような攻撃者は、たいてい一連のランダムなパスワードを使用して Administrator アカウントにログインしようとしますが、アカウント名とパスワードのどちらを誤って推測した場合でも、同じエラー メッセージが表示されます。
つまり、Administrator アカウント名の変更に関する最も重要な主張の 1 つである、スクリプト キディを阻止できるという考えには不備があります。元の Administrator アカウント名から別の名前に変更しても、スクリプト キディはその変更に気付かないので、すぐには攻撃を終了しません。スクリプト キディは、同じ一連のランダムなパスワードを使用して推測を行った後、攻撃できる可能性のある次の標的に移ります。
これは、Administrator アカウントのパスワードが、攻撃に耐えられるほど強力であれば、アカウント名を変更しても、それ以上の価値はもたらされないことを意味します。たとえば、Administrator アカウントに、大文字と小文字、数字、およびキーボード全体から選択した記号で構成される 15 文字のパスワードを設定したとします。このパスワードをネットワーク経由で推測するには、約 591,310,404,907 年かかります。ちなみに、これは宇宙が存在する年数の約 43 倍の年数です。
ここで、Administrator アカウント名を変更することによって、推測にかかる時間を 1,000 倍にしてみましょう。これによって、パスワードの推測にかかる時間は 591,310,404,906,787 年 (宇宙が存在する年数の 43,161 倍) になります。さて、セキュリティは強化されたと言えるでしょうか。3 桁分ですが、もちろん強化されています。攻撃者がパスワードを推測できる可能性を、いくらかでも低下させることはできたでしょうか。いずれにせよ、その効果は非常にわずかです。つまり、実質的には、元の Administrator アカウント名を使用した場合とそれほど差はありません。アカウント名を変更すると、そのアカウント名の使用を試みるマルウェアを撃退できるからといって、アカウント名を変更しなければそのマルウェアを撃退できないと解釈するのは誤りです。実際は、強力なパスワードを使用 (することをお勧めします) すれば、アカウント名にかかわらず、マルウェアを必ず撃退できると言ってもよいでしょう。
多くのセキュリティ ガイダンスでは、Administrator アカウント名の変更を要件として挙げていますが、これは価値の高いセキュリティ対策とは言えず、さらには妥当な対策とも言えません。このような情報によって、この対策を実装するかどうかについて、リスクを考慮した適切な判断を下すことができなくなります。セキュリティ ガイドでは、まったく効果のない設定や、存在すらしない設定を要件として挙げていることが非常によくあります。最終的に、セキュリティを強化するには、これらの要件を 1 つずつ確認し、実際に問題を分析して、要件として挙げられた緩和策が理にかなっているかどうかを評価する必要があります。ここで 1 つ重要なことを思い出してください。それは、攻撃者がある機能を標的にしていても、それだけでは、その機能に変更を加える十分な理由にはならないことです。機能を変更する必要があるのは、変更を加えなかった場合にその機能が攻撃を受けることが十分に予想される場合のみです。
強力なパスワードを設定すれば、アカウント名が変更されたかどうかにかかわらず、攻撃の成功率は事実上ゼロになります。このため、強力なパスワードを設定している限り、セキュリティ上の理由でアカウント名の変更が必要になることはありません。さらに、私と同じように、コンピュータに加える変更が少ないほど、そのコンピュータの安定性は高くなるという原則 (ちなみに、これは一般に定着している事実です) に従って活動している場合、その原則は、当然 Administrator アカウントを変更しない理由としても適用できます。
価値の低い緩和策に焦点を移す 隠すことによるセキュリティを利用した、価値の低い緩和策に移行することの問題点は、組織の焦点を価値の高い緩和策から移さなくてはならないことです。たとえば、Administrator アカウント名を変更する時間と手間を、他の対策に費やすことはできません。その他の対策によって、Administrator アカウント名の変更よりも高い価値がもたらされる場合、組織はその価値を得る機会を逃すことになります。実際のコストには影響しないように思えるかもしれませんが、50,000 個の Administrator アカウント名を変更することを想像すれば、この意味をおわかりいただけるのではないでしょうか。
なお悪いことに、価値の低い緩和策に移行すると、組織の経営陣が手を休めてしまう可能性が非常に高くなります。経営陣は、隠すことによるセキュリティ緩和策によって提供される最低限の価値を必ずしも理解していない場合があり、追加の作業を行わない可能性があります。これは、組織にとって非常に大きなリスクになります。このリスクは、経営陣が、単純に時間と手間をかけて、実装している緩和策の価値を理解すれば、高い確率で回避できます。
管理にかかるコストの大きさ 最後の考慮事項ですが、緩和策がどれくらい適切に実装されるかによって、管理コストは非常に大きくなる可能性があります。グループ ポリシー オブジェクト (GPO) を使用して Administrator アカウント名を変更した場合、コストは非常に小さくなります。この方法によって全員が新しい名前を知ることができるので、展開コストはほぼゼロです。ただし、先ほど述べたように、アカウントを持つユーザー全員がその名前を知ることになるので、最小限の価値しか提供されません。したがって、この緩和策から最大限の価値を得るには、ホストごとに異なる名前を使用する必要があるので、システムの管理コストは非常に大きくなります。
passgen (protectyourwindowsnetwork.com/tools.htm) などのツールを使用して、ネットワーク上のすべての Administrator アカウントに 100 文字の完全にランダムなパスワードを設定し、毎日の管理作業に異なるアカウントを使用した方が、管理コストははるかに小さくなります。純粋に Administrator アカウントを障害回復のみに使用する (Windows Small Business Server 2003 を使用する場合は除きます) と考えれば、ネットワーク管理システムへの影響はまったく発生しません。さらに、攻撃者がいずれかの Administrator アカウントのパスワードを正確に推測することは、太平洋の底に沈む 1 本の針を見つけることよりも困難になります。また、強力な一意のパスワードに重点を置くことによって、スクリプト キディは好きなだけパスワードの推測を続けることができます。

結局はリスク管理が重要
事実上、隠すことによるセキュリティ対策はすべて、今回紹介した方法で分析できます。どの対策にも利点と欠点があり、適切な対策は組織によって異なります。結局、このことがリスク管理上の問題になります。つまり、解決策の実装にコストをかけて、そのリスクを緩和する価値があるかどうかを判断する必要があります。情報資産の保護に関するすべての決定は、十分な情報に基づき、リスクを考慮して行う必要があり、白か黒を選択すれば済むことはほとんどありません。
確かに、いくつかの決定は既に下されています。たとえば、クレジット カードの情報を暗号化しないこと、またはクレジット カードの検証コードを保管しないことのいずれかを選択する場合、どちらを選択した場合でも、可能な支払い形式にクレジット カードが含まれなくなる可能性があります。この決定がビジネスに及ぼす可能性のある悪影響は、選択の幅が狭くなることです。つまり、これは間違いなくリスクを考慮した決定ですが、その決定を下すのは非常に簡単です。
同様に、物理的な店舗の店内ネットワークのバックエンドを制限のないワイヤレス ネットワークに接続する人はいないと思いますが、この接続に関する決定は、リスクを考慮した決定ではありません。リスクを考慮した決定と言えるのは、ある人がその行為を行うことを選択し、ある人が実際にその行為を行った場合、ある人がその結果 (残念ながら実際に起こることはないと思われますが) による不利益を被る場合です。
ここで重要なのは、対処する必要がある問題、その問題への対策、および各対策の利点と欠点を明確に示すことです。これにより、十分な情報に基づいてリスクを考慮した決定を下すために必要な情報が得られます。この情報がなければ、勘に頼って決定を下すことになるので、良い決定になることはほとんどありません。

Jesper M. Johansson は、セキュリティ ソフトウェアの開発に取り組むソフトウェア アーキテクトで、TechNet Magazine の編集にも携わっています。管理情報システムの博士号を持ち、セキュリティ分野で 20 年以上の経験があります。また、エンタープライズ セキュリティの Microsoft MVP でもあります。最新の著書には、『Windows Server 2008 Security Resource Kit』があります。
Roger Grimes (セキュリティの CPA、CISSP、MCSE) は、Microsoft ACE チームのシニア セキュリティ コンサルタントで、これまでに、コンピュータ セキュリティに関する 8 冊の書籍、および 200 を超える雑誌記事を執筆しています。セキュリティ カンファレンスで頻繁に講演を行っており、InfoWorld のセキュリティ コラムニストでもあります。
© 2008 Microsoft Corporation and CMP Media, LLC.All rights reserved; 許可なしに一部または全体を複製することは禁止されています.


セキュリティ
Windows Vista 用の新しい昇格 PowerToy
Michael Murgolo
概要:
  • 管理者としてサードパーティ製のスクリプト ツールを実行する
  • 別のユーザーとして実行する
  • システムとしてコマンド プロンプトと PowerShell プロンプトを開く
  • ドラッグ アンド ドロップで操作できる昇格ガジェット
この記事で使用しているコードのダウンロード: Elevation2008_06.exe (197KB)

Windows Vista 用の "昇格 PowerToy" についての新しい記事へようこそ。2007 年 6 月号の TechNet Magazine では、"昇格 PowerToy" について詳しく説明しました。あれから 1 年がたちました。今回は、"管理者として実行" 機能を私が気に入っているサードパーティ製の
スクリプト ツールでも使用できるように拡張した方法を説明し、この機能を Windows Vista® で廃止された Windows® XP の優れた機能の代わりに使用する方法を説明して、"昇格 PowerToy" で提供している便利なツールをいくつか紹介します。

管理者としてサードパティ製のスクリプト ツールを実行する
前回の記事 (technet.microsoft.com/magazine/cc162321.aspx) で説明したトピックの 1 つは、Windows 付属のスクリプト ツールで [管理者として実行] コマンドを利用できるようにすることでした。今回の記事では、以下のサードパーティ製のスクリプト ツール用に、"管理者として実行 PowerToy" を作成しました。
  • AutoIt v3 (www.hiddensoft.com)
  • AutoHotkey (www.autohotkey.com)
  • ActivePerl (www.activestate.com)
  • KiXtart 2010 (www.kixtart.org)
これらのツールのコードはすべて technetmagazine.com で公開されているこの記事のダウンロードに含まれています。実際のファイルは、それぞれ ElevateAutoIt3.inf、ElevateAutoHotKey.inf、ElevatePerlScript.inf、および ElevateKiXtart.inf という名前です。AutoIt v3、AutoHotkey、および ActivePerl については、セットアップは非常に簡単で、必要な作業は該当アプリケーションをダウンロードして既定の場所にインストールするだけです。必要なアプリケーションをインストールしたら、後は、当該ツール用の "管理者として実行 PowerToy" をインストールするだけです。
残念ながら、KiXtart 2010 にはインストーラが用意されていません。そこで、PowerToy が適切に機能するように KiXtart を標準的な場所にインストールするために、KiXtart 2010 (バージョン 4.60) を Program Files\KiXtart にインストールし、.kix ファイル拡張子を登録する INF ファイルを用意しました。
www.kixtart.org/?p=downloads にアクセスし、KiX2010_460.zip をダウンロードして展開します。Install_KiXtart.inf ファイルを同じフォルダにコピーします (.inf ファイルは、この記事のダウンロードに含まれています)。次に Install_KiXtart.inf ファイルを右クリックし、[インストール] をクリックします。その後は、このツール用の PowerToy (ElevateKiXtart.inf) をインストールするだけです。

別のユーザーとして実行する PowerToy
ユーザー アカウント制御 (UAC) は、ユーザーが管理者の場合でも、ほとんどのアプリケーションを標準ユーザー特権で実行するようにして、オペレーション システムがマルウェアの攻撃を受けにくくすることを目的に作成されました。UAC には、管理タスクやアプリケーションの機能を実行する際に、権限を昇格するオプションが用意されています。この権限の昇格は、実行可能ファイルを右クリックすると表示される [管理者として実行] コマンドを使用して行えます。2007 年 6 月号の記事で紹介した "昇格 PowerToy" では、この機能を拡張して、他のファイルやオブジェクトの種類でも権限を昇格できるようにしました。
Windows Vista に組み込まれている機能は、多くの管理タスクで問題なく動作します。しかし、1 つの重要なシナリオが抜け落ちていました。多くの IT 部門では、ネットワーク管理者は日常的なタスク (電子メールの使用、文書の作成など) に使用するアカウントと、ネットワーク管理 (またはローカル コンピュータの管理) に使用する別のアカウントの 2 つを使用する方針をとっています。
これは、ネットワーク管理者が日常的なタスクを行う際に誤ってマルウェアを実行した場合に、システム全体 (具体的には管理者がログオンしているドメイン) に悪影響が及ぶリスクを抑えるための対策です。Windows XP では右クリックしたときに表示される [別のユーザーとして実行] コマンドを使用して、この操作を実行していましたが、Windows Vista では、このコマンドは [管理者として実行] コマンドに置き換えられたので存在しなくなりました。
ただし、runas コマンド ライン ツールは、まだ Windows Vista に存在しています。残念ながら、このコマンド ライン ツールは、アカウントを 2 つ使用する一般的なタスクの大半 (つまり Microsoft® 管理コンソール (MMC)) では使用できません。たとえば、Active Directory® のアカウント管理タスクを委任されているとします。日常的なタスクは標準ユーザーとして実行しており、必要なときにネットワーク管理ツールをインストールできるように、ネットワーク管理用のアカウントも、UAC が有効になっている Windows Vista コンピュータのローカル Administrators グループのメンバになっています。このような場合に、Active Directory ユーザーとコンピュータ (ADU&C) を Active Directory の管理アカウントで起動する必要が生じて、次のような runas コマンドを実行したとします。
runas /user:mydomain\admin
"mmc.exe %windir%\system32\dsa.msc"
残念ながら、上記のコマンドを実行しても ADU&C は起動されず、"要求された操作には管理者特権が必要です" という runas のエラー メッセージが表示されます。この現象は、MMC の実行可能ファイルが highestAvailable 特権レベルで実行されるようにマークされていることが原因で発生しています。ネットワーク管理用アカウントの highestAvailable レベルは管理者として実行することなので、この方法で ADU&C を起動するには権限の昇格が必要ですが、runas では権限の昇格の確認が行われないので、エラーが発生します。
Windows Vista では、[別のユーザーとして実行] に相当するショートカット メニューのコマンドが用意されておらず、昇格が必要なプロセスを別のユーザーとして実行する組み込みの手段もないので、このシナリオが難しくなっています。
この問題の解決策がなければ、この記事はストレスのたまる記事になったでしょう。しかし幸運にも、前回の記事で紹介した "昇格 PowerToy" の 1 つから 2 つ目の問題を解決する鍵が得られたので、私は別の PowerToy を作成して 1 つ目の問題を解決しました (私が昇格の問題の解決策を思い付いたと主張できればよかったのですが、これを思い付いたのは Windows アプリケーション互換性チームの Gov Maharaj でした)。
"昇格コマンド PowerToy" は runas コマンドと共に使用できることがわかりました。上記のコマンドでは権限の昇格の確認が行われませんでしたが、次のコマンドでは確認が行われます。
runas /user:mydomain\admin
"elevate mmc.exe%windir%\system32\dsa.msc"
このコマンドを実行すると elevate.cmd が他のユーザーとして起動し (厳密には、起動されるプロセスは cmd.exe です)、elevate コマンド スクリプトによって権限の昇格の確認が行われ、mmc.exe が起動されます。
右クリックしたときに [Run as Another User] (別のユーザーとして実行) コマンドを提示する PowerToy を作成するために、.exe ファイルと .msc ファイルのファイルの関連付けと組み合わせて、HTML アプリケーションの UI を使用するという裏技を使用しました。[Run as Another User] (別のユーザーとして実行) をクリックすると、図 1 のような HTML アプリケーションが表示されます。
図 1 別のユーザーとして実行するツール
図 1 別のユーザーとして実行するツール (画像を拡大するには、ここをクリックします)
ここで必要な作業は、ローカル コンピュータのアカウントのユーザー名とドメインを入力し、[Use Local Account] (ローカル アカウントを使用する) チェック ボックスをオンにするだけです。[Run] (実行) をクリックするとアプリケーションが標準ユーザーで起動し、[Run as Admin] (管理者として実行) をクリックするとアプリケーションが昇格された権限で起動します。どちらかのボタンをクリックすると、runas.exe が実行され、パスワードまたはスマート カードの PIN を入力するように要求されます。
この PowerToy では "昇格コマンド PowerToy" を使用しているので、まず "昇格コマンド PowerToy" をインストールする必要があります。RunAs.inf を右クリックし、[インストール] をクリックして、権限の昇格を承認します。この PowerToy をアンインストールするには、コントロール パネルのプログラムと機能を使用します。
一部の管理ツールの .msc ファイルへのショートカット (コンピュータの管理など) は、この PowerToy と連動しています。しかし、adminpak.msi を使用して Windows Server® 2003 管理ツールをインストールした場合、作成されたショートカットは .msc ファイルへの標準的なショートカットではないことに注意してください。これらのショートカットは Windows インストーラのショートカットなので、右クリックしても [Run as Another User] (別のユーザーとして実行) コマンドは表示されません。
このようなショートカットについては、実際の .msc ファイルを探して右クリックするか、.msc ファイルへの新しいショートカットを作成する必要があります。また、Windows Vista で Internet Explorer® のアーキテクチャが保護モード用に変更されたことが原因で、runas は Internet Explorer と連動しません (この問題の詳細については、support.microsoft.com/?id=922980 を参照してください)。
注 : 前回の記事で紹介した PowerToy が完成してから、この記事を公開するまでの間に、Windows Sysinternals から、"別のユーザーとして実行 PowerToy" と非常によく似た機能を持つ新しいツールがリリースされました。このツールは ShellRunas という名前で、Windows Sysinternals のサイト (technet.microsoft.com/sysinternals/cc300361) から入手できます。
Sysinternals の開発者は実際に業務で本物のコードを記述しているので、皆さんが使用する場合は、こちらのツールを使用することをお勧めします。私が作成したツールについては、スクリプト コードと HTML アプリケーションを使用して、具体的にはこのタスクが、また一般的にはシェル拡張が実行される例として、この記事に残すことにしました。

システムとしてコマンド プロンプトと PowerShell プロンプトを開く
プログラムをローカル システム コンテキストで実行しなければならないことがあります。たとえば、System Center Configuration Manager (SCCM) など、多くのソフトウェア配布ツールでは、ローカル システムとして実行されるクライアント エージェントを使用して作業を実行します。
ローカル システムとして実行されるソフトウェア インストール プログラムを、SCCM などの製品で配布する前に、プログラムの動作を確認するには、ローカル システムとして実行したコマンド プロンプトを使用してインストーラを起動すると便利です。そのため、"システムとしてコマンド プロンプトを開く PowerToy" と "システムとして PowerShell プロンプトを開く PowerToy" を作成しました。
Windows XP を使用していたときは、このような機能は、コマンド シェル スクリプトを使用して次のように実行していました。
@echo off
sc create CmdAsSystem type= own type= interact
binPath= "cmd /c start cmd /k (cd c:\ ^& color ec ^&
title ***** SYSTEM *****)"
net start CmdAsSystem
sc delete CmdAsSystem
しかし、このスクリプトを Windows Vista で管理者特権で起動したコマンド プロンプトから実行すると、次のようなエラー メッセージが表示され、システムとして実行されるコマンド プロンプトは表示されません。
警告 : サービス CmdAsSystem は対話型として構成されていますが、対話型の構成は推奨されていません。サービスは正しく機能しない可能性があります。
問題は、このスクリプトでは対話型サービスを作成して起動しようとしている点です。Windows Vista では、対話型サービスは Session 0 分離のために正しく機能しません (Session 0 分離の詳細については、「Windows Vista のサービス」ホワイト ペーパー (microsoft.com/whdc/system/vista/Vista_Services.mspx) を参照してください)。
この制約に対処するため、私は Sysinternals によって開発された PsExec というツールを使用しました (このツールの詳細については、technet.microsoft.com/sysinternals/bb897553.aspx を参照してください)。このツールを使用すると、プロセスをシステム コンテキストで起動できます。残念ながら、ほとんどの Sysinternals ツールにはインストーラが用意されていません。そこで、Sysinternals Suite 全体 (PsExec を含む) を Program Files\Sysinternals Suite にインストールする INF ファイルを用意しました (このファイルはダウンロードに含まれています)。さらにおまけとして、この INF ファイルを使用すると、[スタート] メニューに Sysinternals Suite のグラフィカル ツールのショートカットが作成されます。
Sysinternals Suite をインストールするには、まず SysinternalsSuite.zip を technet.microsoft.com/sysinternals/bb842062.aspx からダウンロードして展開します。Sysinternals Suite を展開したフォルダに、私が作成した INF ファイル (Install_SysinternalsSuite.inf) をコピーし、Install_SysinternalsSuite.inf ファイルを右クリックして、[インストール] をクリックします。この新しい PowerToy では "昇格コマンド PowerToy" を使用しているので、"昇格コマンド PowerToy" をインストールします。ここまでの作業が終わったら、CmdHereAsSystem.inf と PowerShellHereAsSystem.inf をインストールできます。これらの PowerToy をインストールすると、Windows エクスプローラのフォルダやドライブを右クリックしたときに、[CMD Prompt Here as System] (システムとしてコマンド プロンプトを開く) および [PowerShell Prompt Here as System] (システムとして PowerShell プロンプトを開く) コマンドが表示されるようになります (図 2 参照)。
図 2 [CMD Prompt Here as System] (システムとしてコマンド プロンプトを開く) と [PowerShell Prompt Here as System] (システムとして PowerShell プロンプトを開く)
図 2 [CMD Prompt Here as System] (システムとしてコマンド プロンプトを開く) と [PowerShell Prompt Here as System] (システムとして PowerShell プロンプトを開く)
図 3 は、システムとして実行されているコマンド プロンプトを示しています。このプロンプトがシステムとして実行され、間違ったコマンドを入力するとシステムに予期しない (損害が発生する) 影響を与える可能性があることを示すために、鮮やかな色を採用しました。
図 3 システムとして実行されるコマンド プロンプトは責任を持って使用する必要がある
図 3 システムとして実行されるコマンド プロンプトは責任を持って使用する必要がある
最後に、これらの PowerToy では、これらのコマンドがシステム コマンドに追加されるので、上記のコマンド プロンプトは [ファイル名を指定して実行] ダイアログ ボックスまたはコマンド プロンプトから起動できます。たとえば、以下のコマンドを [ファイル名を指定して実行] ダイアログ ボックスで実行すると、コマンド プロンプトがシステムとして実行され、Windows フォルダがカレント ディレクトリになります。
cmdassystem "c:\windows"
Windows PowerShellTM の対応するコマンドは、psassystem です。また、"管理者としてコマンド プロンプトを開く PowerToy" と "管理者として PowerShell プロンプトを開く PowerToy" も変更して、それぞれ cmdasadmin と psasadmin という同様のコマンドがインストールされるようにしました。

昇格ガジェット
私が作成した PowerToy の大半では、マウスの右ボタンをクリックする必要があります。しかし、今回の更新のおまけとして、もう少しおもしろい機能も含めました。これは、私が "昇格ガジェット" と呼んでいる Windows サイドバー ガジェットです (図 4 参照)。このガジェットはドラッグ アンド ドロップで操作できます。Windows エクスプローラから、runas コマンドが定義されている実行可能ファイルまたはスクリプトをドラッグするだけで、ファイルが昇格された権限で起動されます。
図 4 ドラッグ アンド ドロップで操作できる昇格ガジェット
図 4 ドラッグ アンド ドロップで操作できる昇格ガジェット
前回の記事で紹介した "昇格 PowerToy" をインストールしている場合、この PowerToy は Windows スクリプト ホスト スクリプト、Windows PowerShell スクリプト、HTML アプリケーション、および Windows インストーラ パッケージと修正プログラムに使用できます (もちろん Windows Vista で runas コマンドが既定で定義されている実行可能ファイルとコマンド シェル スクリプトにも使用できます)。さらに、一度に複数の項目をドラッグすることもできます (フォルダをガジェットにドラッグして、結果を確認してみてください)。
ガジェットをインストールするには、Elevation.gadget をダブルクリックします (このファイルもダウンロードに含まれています)。ガジェットのコードを確認するには、ファイル名に .cab 拡張子を追加します。その後、CAB ファイルから内容を展開できます。

まとめ
この記事のダウンロードには、新しい PowerToy と、前回の記事で紹介した PowerToy の両方が含まれています。前回の記事で紹介した PowerToy の一部には少し変更を加えました。たとえば、以前のバージョンの "管理者として Windows PowerShell Prompt を開く PowerToy" と "WSH スクリプトの昇格 PowerToy" では、どちらも専用の elevate.cmd と elevate.vbs のコピーをインストールしていました。いくつかの新しい PowerToy は、これらのファイルに依存しているので、このような PowerToy では、"昇格コマンド PowerToy" のインストールを要求するようにしました (インストール後は、同じファイルを共有します)。ある特定の PowerToy に "昇格コマンド PowerToy" のインストールが必要かどうかを判断するには、INF ファイルのヘッダーを確認してください。
その他の以前のバージョンの PowerToy の一部にも、機能に関係ないちょっとした変更を加えています。必ず古いバージョンの PowerToy をアンインストールしてから最新バージョンの PowerToy をインストールしてください。今回の記事を執筆するにあたり、このコレクションは 17 種類のツールに拡大したので、コレクション全体をインストールまたはアンインストールするコマンド シェル (InstallAllPowerToys.cmd と UninstallAllPowerToys.cmd) を用意しました。これらのコマンド シェルをカスタマイズして、使用する必要があるツールだけをインストールまたはアンインストールすることができます。
既定では、InstallAllPowerToys.cmd を実行しても、サードパーティ製のスクリプト ツールに対応した "管理者として実行 PowerToy" はインストールされないことに注意してください。このスクリプトは、対応するソフトウェアがインストールされている PowerToy だけをインストールするように変更できます。いずれかのスクリプトを実行すると、スクリプトは昇格された権限で再起動されます。UninstallAllPowerToys.cmd を実行すると、すべての古いバージョンの PowerToy もアンインストールできます。
私が作成した他のすべての PowerToy と同様に、今回紹介した PowerToy についてはサポートを提供していないので、各自の責任でご使用いただくことになります。また、これらの PowerToy は公式なマイクロソフト製品ではなく、私が個人的に作成したものです。私と他の数人のボランティアによって、英語 (米国) を既定の言語として使用している 32 ビット版の Windows Vista でテストされているだけです。また、これらの PowerToy のいずれか、またはすべてが、今後リリースされる Windows の更新プログラム、サービス パック、またはオペレーティング システムのバーションで動作しなくなる可能性があることをご了承ください。

Michael Murgolo は Microsoft Consulting Services のシニア インフラストラクチャ コンサルタントです。得意分野は、オペレーティング システム、展開、ネットワーク サービス、Active Directory、システム管理、自動化、修正プログラム管理です。デスクトップの展開および移行の分野を専門にしています。


セキュリティ
BitLocker ドライブ暗号化の強化点
Byron Hynes
概要:
  • BitLocker の強化点
  • BitLocker を入手し、インストールする
  • サーバー上で BitLocker を使用する
  • 完全なデータ保護を実現するための注意点

昨年の TechNet Magazine のセキュリティ特集号では、Windows BitLocker ドライブ暗号化のいくつかの機能を簡単に紹介し、Windows Vista の初期リリースでこの機能がどのように実装されているかについて説明しました。最近、
Windows Vista® Service Pack 1 と新しい Windows Server® 2008 オペレーティング システムがリリースされたため、今回再び BitLocker® を取り上げることにしました。
この記事では、最新バージョンで加えられたいくつかの変更点を紹介し、BitLocker をサーバーにインストールして使用する方法について概説します。また、注意が必要な最近の報道についても取り上げます (なお、昨年の記事「BitLocker ドライブ暗号化を使用したデータ保護の概要」については、technet.microsoft.com/magazine/cc138009.aspx を参照してください)。

新機能
今回の BitLocker のリリースで導入された変更点は、基本的な操作を変えることなく、新たな柔軟性を実現しています。この記事では、これらの変更点のうち、コンピュータへのアクセスに 3 要素認証を使用することを可能にするデータ ボリュームのサポート、64 ビット システム用の新しい業界標準のファームウェアである Unified Extensible Firmware Interface (UEFI) のサポート、ボリューム メタデータの暗号化攻撃に対する保護の強化、およびトラステッド プラットフォーム モジュール (TPM) の使用の拡大について説明します。

データ ボリューム
Windows Vista の初期リリースで提供された BitLocker コントロール パネルでは、Windows® オペレーティング システム ボリューム (通常は C: ドライブ) の暗号化のみを有効にできました。通常、家庭用コンピュータは、ユーザーのデータとプログラムがすべてオペレーティング システムと同じボリューム上に保存されるように構成されているため、多くの消費者にとってはこれで十分でした。ただし、ビジネス環境、特にサーバー上では、このような構成が使用されないことがよくあります。このため、最も多かった顧客からの要望の 1 つは、データ ボリューム、つまりコンピュータ上にある OS ボリューム以外のボリュームを暗号化できる機能でした (BitLocker はリムーバブル メディアを暗号化できるようには設計されていないことに注意してください)。
図 1 の例では、コンピュータ上に 3 つの使用可能なボリュームがあります (スタートアップに使用する小さなアクティブ パーティションまで含めると、実際には 4 つです)。オペレーティング システムは、C: ドライブにインストールされています (これは、アイコンに付いた Windows の "旗" によって表されています)。この他に E: と P: という 2 つのボリュームがあります。P: ボリュームは既に BitLocker によって暗号化されており、現在はロックされています。E: ボリュームは暗号化されていません。Windows Vista SP1 と Windows Server 2008 では、BitLocker コントロール パネル アプレットから、これらのデータ ボリュームの暗号化とロック解除を行うことができます。
図 1 Bitlocker のインターフェイス
図 1 Bitlocker のインターフェイス (画像を拡大するには、ここをクリックします)
既定では、オペレーティング システム ボリュームが BitLocker によって暗号化されている場合、オペレーティング システム ボリュームのロックが解除されると、暗号化されているデータ ボリュームのロックも必ず解除されます。コントロール パネルを使用してデータ ボリュームのロックを解除する場合、このオプションがチェック ボックスとして表示されます (図 2 参照)。
図 2 自動ロック解除用のキーを保存する
図 2 自動ロック解除用のキーを保存する (画像を拡大するには、ここをクリックします)
データ ボリュームの "自動ロック解除" を有効または無効にするには、manage-bde.wsf コマンド ライン ツールを使用します。Manage-bde.wsf は Windows に付属している強力なスクリプトで、BitLocker と共にインストールされる Windows Management Instrumentation (WMI) プロバイダを基盤として使用します。
たとえば、データ ボリューム P: をマークして、手動でなければロックを解除できないようにするには、次のコマンドを使用します。
manage-bde.wsf –autounlock –disable P:
P: の自動ロック解除を再び有効にするには、次のコマンドを使用します。
manage-bde.wsf –autounlock –enable P:
BitLocker コントロール パネルでは、BitLocker とデータ ボリュームを使用して行うことができるすべての操作が提供されるわけではないため、-? オプションを使用して、manage-bde.wsf コマンドの詳細を確認してください。manage-bde.wsf の構文は、『Windows BitLocker ドライブ暗号化デザイン ガイド』と『Windows BitLocker ドライブ暗号化展開ガイド』にも記載されています。これらのガイドは Microsoft ダウンロード センター (go.microsoft.com/fwlink/?LinkId=115215) からダウンロードできます。

TPM、USB、PIN の組み合わせ
BitLocker で使用できる認証要素の追加を望む声も顧客から多く聞かれました。BitLocker は、コンピュータの TPM チップを使用して、プラットフォームの整合性を検証します。つまり、BIOS を含む初期起動コンポーネントが改変されたり、破損していないかどうかを確認します。ただし、Windows Vista のリリース以降は、PIN、または BitLocker を有効にしたときに作成されたキーが保存されている USB フラッシュ ドライブを要求することもできるようになりました。
Windows Server 2008 と Windows Vista SP1 では、これら 3 つの要素をすべて組み合わせることができます。TPM は引き続きプラットフォームの整合性を検証し、USB キーは "ユーザーが持っているもの"、PIN は "ユーザーが知っているもの" を表します。この構成によって、権限のないユーザーによるコンピュータの起動や、BitLocker によって保護されたドライブのロック解除に対して、非常に強力な保護が提供されます。
ただし、セキュリティの世界ではよくあることですが、これにもトレードオフがあります。BitLocker をこのように構成すると、コンピュータを自動的に再起動することはまずできません。たとえば、サーバーの場合は、シームレスな再起動とより高度な保護のどちらが重要であるかを判断する必要があります。

UEFI のサポート
Windows Server 2008 と Windows Vista SP1 では、Unified Extensible Firmware Interface (UEFI) が搭載されているコンピュータのサポートも追加されました。UEFI は、ほとんどのコンピュータが起動時に使用する従来の BIOS を近代化した仕様です。UEFI の詳細については、www.uefi.org を参照してください。

強化された保護
BitLocker がシステムの変更を検出した場合、または必要な PIN や USB キーが起動時に提供されなかった場合、BitLocker は回復モードに入ります。回復モードでは、BitLocker が有効になっているボリュームのロックが維持され、回復コンソールというテキスト モードのダイアログ ボックスが表示されます。
ドライブのロックを解除するには、回復パスワード (48 桁の数字) をキーボードか USB フラッシュ ドライブから入力する必要があります (USB フラッシュ ドライブに保存された回復パスワードは、テキストではなくバイナリ形式であるため、回復キーと呼ばれることがあります)。
BitLocker は、回復パスワードを使用し、ボリューム メタデータ内に保存されているキー (まずボリューム マスタ キー (VMK)、次にフルボリューム暗号化キー (FVEK)) を解読することによって、ドライブのロックを解除します。正常に回復を完了するには、回復パスワードのコピーを提供する必要があります。
このため、ユーザーが回復パスワードを (USB フラッシュ ドライブなどに) 保存するだけでなく、管理者もこのパスワードを一元管理し、保存しておくことを強くお勧めします。オペレーティング システムには、Active Directory® ドメイン サービス (ADDS) に回復パスワードを保存する機能も実装されています。
ボリューム メタデータ内に保存されているシークレット (VMK など) は暗号化されています。また、暗号化によってボリューム メタデータ全体の整合性が維持されます。BitLocker がボリューム メタデータの改ざんを検出した場合、そのメタデータの使用は拒否され、保護ボリュームのロックは解除されません。この状態では、回復パスワードのみを使用してドライブのロックを解除することはできません。
ただし、このような状況が発生するのは、コンピュータが計画的なセキュリティ攻撃の被害に遭った場合のみです。この場合、おそらくコンピュータは既に悪意のある人物の手に渡っているため、それ以上なす術はないでしょう。計画的でない単純な変更がプラットフォームに加えられた場合や、PIN を忘れた場合、このような状況は発生しません。
ボリュームのロックを解除するには、次の 3 つが必要です。
  • 回復パスワード (キーボードからテキストを入力するか、USB フラッシュ ドライブを使用します)
  • 暗号化された FVEK と VMK が格納されているバイナリ キー パッケージ
  • Bitlocker 修復ツール
つまり、管理者は、企業内で上記の 3 つをいつでも利用できるようにしておく必要があります。
回復パスワードは、手動でも自動でもバックアップできます。個人的には、グループ ポリシー設定を使用して、回復パスワードを Active Directory ドメイン サービスに自動的にバックアップすることをお勧めします。
この設定を構成する場合は、バイナリ キー パッケージをバックアップするオプションも指定してください (図 3 参照)。このバイナリ キー パッケージには、暗号化された VMK と FVEK が含まれているため、必要に応じて BitLocker 修復ツールを使用できます。
図 3 回復情報にキー パッケージを含めるようにグループ ポリシーを構成する
図 3 回復情報にキー パッケージを含めるようにグループ ポリシーを構成する (画像を拡大するには、ここをクリックします)
BitLocker 修復ツールは、BitLocker が有効になっているディスクが破損した場合に、そのディスクのデータ回復を支援することを目的としています。これは高度なツールであり、経験豊富な管理者が使用することを想定しています。BitLocker 修復ツールの詳細については、マイクロソフト サポート技術情報の記事 (support.microsoft.com/kb/928201) か、私の Web キャスト (ライブ デモも含まれています)「企業における Microsoft BitLocker: BitLocker ツールの活用方法」(go.microsoft.com/fwlink/?LinkId=114985) を参照してください。
ここで指摘しておきますが、BitLocker を使用しても、データのバックアップが必要なことに変わりはありません。ディスクが破損した場合や、計画的な攻撃の被害を受けた場合、BitLocker 修復ツールを使用しても、なんらかのデータを (すべてのデータとなればなおさら) 回復できる保証はありません。

拡大する TPM の使用
技術的に見れば、これは BitLocker の変更点ではありませんが、ここで取り上げるだけの価値はあります。SP1 の前のバージョンでは、BitLocker が TPM を使用する唯一の Windows OS コンポーネントでしたが、その他の機能でも TPM が使用されるようになりました。たとえば Windows は、TPM を使用できることを検出した場合、乱数の生成時に TPM を使用し、エントロピーを増大させます。これにより、あらゆる種類の暗号化の質が向上します (また、ゲームのパフォーマンスも向上する可能性があります)。
ただし、TPM の使用が拡大したことによって、イベント ビューアに表示される TPM 関連のイベントが必ずしも BitLocker に関するイベントではなくなります。IT プロフェッショナルは、他のシステム コンポーネント (および可能性としては、他のベンダのソフトウェア) が TPM を使用することによって、イベントがログに記録されることに注意する必要があります。

Windows Server 2008 における BitLocker
Windows Vista と Windows Server 2008 は同じコード ベースを使用しているため、Windows Vista SP1 で BitLocker に加えられた変更は、Windows Server 2008 でも実装されています。ですが、サーバーと BitLocker との間にはどのような関係が存在するのでしょうか。結局、BitLocker の目的は、コンピュータをオフライン攻撃から保護することです。つまり、BitLocker によって、実行中のシステムやサーバーは保護されません。また、サーバーは常時実行されているのが当然であると考えられています。
ただし、サーバー自体、またはサーバーから取り外されたハード ディスクがオフライン攻撃にさらされる可能性があることがわかりました。このような攻撃が実際に発生しないとしても、BitLocker はサーバーやハード ディスクを廃棄する際に、非常に役立ちます (これについては後述します)。まず、サーバー上に BitLocker をインストールし、実行する方法について説明します。

BitLocker を入手し、インストールする
BitLocker は、Windows Server 2008 のすべてのエディションでオプション コンポーネント (機能) として提供され、サーバー マネージャまたはコマンド ラインからインストールする必要があります。BitLocker の一部は、NTFS フィルタ ドライバとして実装されています。このフィルタ ドライバをインストールするには、コンピュータを再起動する必要があるため、サーバー上で BitLocker を有効にすると再起動が必要になることに注意してください。また、Windows Vista の場合と同様、Windows Server 2008 の BitLocker も分割読み込み構成を必要とします。これは、コンピュータの起動に使用されるアクティブ パーティションが暗号化されていない状態を維持する構成です。BitLocker ドライブ準備ツールは、製造元によってあらかじめサーバーが構成されていない場合に、BitLocker をサポートするようにハード ディスクを正しく構成できるツールです。ただし、ハード ドライブのパーティション分割作業に慣れている場合は、もちろんハード ディスクを手動で構成してもかまいません。
BitLocker を Windows Server 2008 にインストールするには、サーバー マネージャのグラフィカル インターフェイスを使用して、機能の一覧から BitLocker を選択するか (図 4 参照)、サーバー マネージャのコマンド ライン インターフェイスからコマンドを実行します。
図 4 サーバー マネージャで BitLocker を選択する
図 4 サーバー マネージャで BitLocker を選択する (画像を拡大するには、ここをクリックします)
ServerManagerCmd –install BitLocker –restart
サーバー マネージャを使用すると、BitLocker と BitLocker 用の管理ツールがインストールされます。また、BitLocker 自体をインストールせずに、管理コンポーネントをインストールすることもできます。この操作を行った場合、フィルタ ドライバが含まれないため、再起動を回避できます。この管理コンポーネントの名前は "RSAT-BitLocker" です。
BitLocker は、Server Core インストールを実行しているコンピュータ上でも問題なく機能しますが、Server Core ではサーバー マネージャを使用して BitLocker をインストールしたり、グラフィカル ユーザー インターフェイスを使用して BitLocker を管理したりできません。コンポーネントのインストールには、コマンド ライン ツールの pkgmgr または ocsetup を使用します。
BitLocker バイナリをインストールし、必要な分割読み込み構成になるようにディスクを構成したら、OS ボリュームで BitLocker を有効にできます。Windows Server 2008 の BitLocker コントロール パネル アプレットでは、Windows Vista SP1 と同じアイコンとオプションが提供されます。BitLocker の詳細モードを有効にするには、ローカル ポリシー エディタを使用するか、グループ ポリシー オブジェクトをサーバーに適用することによって、既定の設定を調整する必要があります。
Server Core インストールを実行している場合、または単にコントロール パネルを使用したくない場合は、manage-bde.wsf を使用して BitLocker を有効にできます。ドライブ C: で BitLocker を有効にするには、次のコマンドを実行します。
manage-bde.wsf –on C: -RecoveryPassword –RecoveryKey F:\
C: は暗号化するボリューム、F:\ は回復キー (バイナリ形式) を保存する USB キーやその他のボリュームを表します。UNC パスを使用して、ネットワーク ドライブ上に回復キーを保存することもできます。また、回復パスワード (数値テキスト形式) も生成および表示されます。ハードウェア プラットフォームが BitLocker の要件をすべて満たしていることが保証されている場合は、–skiphardwaretest パラメータを追加するとよいでしょう。これにより、再起動を 1 回省くことができます。

サーバーのシナリオ
ここでは、サーバー上で BitLocker が役立つ具体的なシナリオをいくつか紹介します。先ほども述べたように、BitLocker は、オフライン攻撃 (Windows が実行されていないときに行われる攻撃) からの保護を目的としていることに注意してください。
ブランチ オフィス まず、サーバー上で BitLocker を使用する最もわかりやすい例は、Windows Server 2008 のブランチ オフィス戦略の一環として使用する場合です。すべてのサーバーの 3 分の 1 ～ 4 分の 1 が、ブランチ オフィス、つまり、物理的なセキュリティが比較的弱く、IT サポートを受けにくく、おそらくデータセンターへの接続回数も少ないオフィスに配置されています。ブランチ オフィスは、攻撃者にとって魅力的なターゲットでもあります。機密データをブランチ オフィスに保存すると便利であるが、それではデータセンターに保存した場合ほど容易にデータを物理的に保護できない場合、BitLocker を読み取り専用ドメイン コントローラ (RODC) などの機能と組み合わせて使用すると役立ちます。
これは、適切なレベルの保護について考える良い機会になります。データへの不正アクセスを防止することと、追加作業を行うことなくサーバーを直ちに利用できるようにすることは、どちらが重要でしょうか。個人的には、多くのブランチ オフィスでは、サーバーを再起動する際に PIN の入力を要求しても問題ないと思いますが、これはそれぞれの企業が決めることです。
配送中のディスク ハード ドライブ上のデータを遠隔地に配送しなければならないことがよくあります。これには、ディスク自体を配送する場合も、サーバー全体を事前に構成して配送する場合も含まれます。配送中は、このようなディスク上のデータを管理することはできないため、データがコピー、紛失、または盗難に遭う可能性があります。
このようなリスクを軽減するには、配送前にコンピュータのボリュームで BitLocker を有効にし、回復キーまたは回復パスワードを除くキーの保護機能をすべて削除します。回復キーまたは回復パスワードは、サーバーとは別に手渡しするか、電話や暗号化された電子メールを使用して、送付先のスタッフに伝えることができます。コンピュータまたはディスクが到着したら、回復パスワードを使用して、ドライブのロックを解除します。受け取ったドライブは、必要に応じて、暗号化されたままにすることも (他のキーの保護機能を再度追加します)、完全に暗号化を解除することもできます。
これは、ブランチ オフィス用のドメイン コントローラやサーバーを事前に準備する場合、特に有効です。
サーバーの盗難 前のセクションで触れたように、サーバー (特にドメイン コントローラ) の盗難という非常に現実的な危険性が存在します。ラップトップは格好のターゲットかもしれませんが、慎重な計画によってサーバーがターゲットとして選択される場合もあります。TPM による整合性の確認のみを要求するように BitLocker が構成されている場合は、単純に盗んだサーバーの電源を入れれば、そのサーバーを簡単に起動できるでしょう。対照的に、サーバーのドライブが BitLocker によって保護されており、BitLocker が詳細モードで構成されている (USB キーと PIN のいずれかまたは両方が要求される) 場合、ある程度の時間内に有用な情報を取り出すことは非常に困難です。
ディスクの盗難 ただし、先ほどの場合とは逆に、ディスクのみが盗まれた場合でも、TPM によって非常に高いレベルの保護が提供されます。BitLocker によって保護されたドライブのロック解除に使用できるのは、元のサーバーの TPM のみであるため、ディスクを単純に別のコンピュータに取り付けても、そのデータを読み取ることはできません。
攻撃を受ける可能性の低減 TPM チップを搭載したサーバー ハードウェアを購入し、BitLocker プラットフォームで整合性の確認を実行することによって、一部のマルウェアに対する保護を強化できます。具体的には、BitLocker によって、Windows のオフライン時に加えられた変更や、初期起動コンポーネントの変更が検出されます。特にルートキットなど、マルウェアが自身のインストールに再起動を必要とする場合、このような保護が提供されます。これは総合的なソリューションではありませんが、Windows で提供されるコードの整合性などの機能や、Microsoft® ForefrontTM Client Security などの製品と組み合わせることによって、多層防御を構成する有効な層をもう 1 つ追加できます。
安全な廃棄 BitLocker の最も有用なシナリオの 1 つは、サーバーやディスクのライフサイクルにおける最後の場面で登場します。サーバーやそのディスクが適切に処理されないまま廃棄されているという話は、頻繁に耳にしたことがあるでしょう。使用済みのハード ドライブは、新しいハード ドライブよりもオークションで高値で売られています。これは、道徳観のない買い手がディスクから有用な情報を取り出すことができるのではないかと考えるためです。
さいわい、費用や時間をかけずにディスクから有用なデータを消去できる方法が、BitLocker によって提供されます。BitLocker を使用すると、基本的に情報は有用な形式でディスクに書き込まれません。暗号化されたデータは使い物にならず、すべてのキー情報はすばやく容易に削除できます。その後は、販売、リサイクル、異なる目的での再利用など、このディスク ハードウェアに何が起きても問題はなく、悪意のあるユーザーの手にデータが渡る心配はありません。
Windows Vista と Windows Server 2008 では、複数の上書きなど、BitLocker キーを削除できるようにフォーマット コマンドが更新されています。このため、単純かつ効率的な方法でドライブを廃棄できるようになりました。

最近の報道
記事の公開までに数週間かかるのは承知していますが、本稿の執筆時点では、最近多数の記事、新聞、ニュースで、興味深いハードウェアの特性と、それがどのように BitLocker や他の Windows セキュリティ機能、およびさまざまなベンダが提供している暗号化製品に影響するかが話題になっています。ここでは、いくつかの調査結果を簡単にご紹介します。
1 つはプリンストン大学の研究者によって発表されたもので、現代のコンピュータ メモリには情報が残ることを (非常に効果的に) 証明しています。これは "DRAM 内残留" と呼ばれることもあります (citp.princeton.edu/pub/coldboot.pdf 参照)。簡単に言うと、コンピュータ メモリ内の情報には、メモリへの電力が遮断された後も一定の期間アクセスできるという主張です。もちろん、Windows の実行中に、メモリ内のデータの暗号化を解除するキーが BitLocker によって保持されるため、権限のないユーザーがキーを入手することが懸念されます。
また、Adam Boileau 氏 (security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf) は、IEEE 1394 (FireWire と呼ばれることがよくあります) によってダイレクト メモリ アクセス (DMA) が可能になることを実証しています。この手法を使用すると、Windows からシークレット (パスワードや暗号化キーなど) を取得できます。これについて興味深いのは、DMA が IEEE 1394 の特性であると言ってもよいことです。これは欠陥ではなく、Firewire の仕様です。
ただし、どちらの攻撃にも共通していることは、稼働中の (または少なくともごく最近まで稼動していた) コンピュータに物理的にアクセスする必要があることです。BitLocker は、オンライン攻撃に対する保護を提供するようには設計されておらず、またこの機能を有効にしても、ある程度の物理的なセキュリティは必要です。適切な多層防御を実装するには、さまざまなツールと機能を使用して物理的なセキュリティ環境を構築するだけでなく、企業の基本方針を策定し、継続的にユーザーを教育する必要があります。
また、これらは新しい発見ではありません。大分前から知られていることで、実際、Microsoft® Data Encryption Toolkit (DET) でも取り上げられています。DET で提供されているリスク分析は、顧客がセキュリティとユーザビリティ、およびセキュリティと実装および管理コストのバランスを考える際の参考資料として使用することを目的としています。このバランスを考える作業を軽視してはいけません。マイクロソフトでは、十分な知識を身に付けた顧客こそが、セキュリティ、ユーザビリティ、およびコストのトレードオフについての決断を下す資格があると考えています。
DET の他にも、何人かの私の同僚が、すばらしい解説とガイダンスを提供しています。まず、Russ Humphries は、ブログ記事 (go.microsoft.com/fwlink/?LinkId=115217) の中で、DRAM 内残留に関連するセキュリティのトレードオフについて述べています。また、Douglas MacIver は、System Integrity (SI) チームのブログ (go.microsoft.com/fwlink/?LinkId=115218) で、さらに具体的な構成手順や今すぐ実施できる対策について説明しています。この 2 つの有用なブログ記事を読まれることを強くお勧めします。また、DET にも目を通してください。
上記の推奨記事で述べられている特に重要なことは、詳細モードを使用する (つまり、USB キーか PIN を要求する) こと、およびスリープ モードでコンピュータを放置しないようにする (代わりに休止モードにする) ことです。

まとめ
BitLocker は、現在でも Windows Vista の最も便利な機能の 1 つです。SP1 リリースにおいて、BitLocker は顧客の意見に直接応える形で機能強化され、さらに多くのシナリオを可能にし、データ保護に関するより幅広いニーズに対応できるようになりました。オフライン時のデータ保護機能が Windows Server 2008 にも組み込まれたことで、データの保存先が、サーバーまたはクライアント ワークステーションのいずれであるか、およびデータセンター、ブランチ オフィス、またはモバイル ワーカーのデバイスのいずれであるかに関係なく、より多くの方法でデータを保護し、整合性を維持できるようになりました。

Byron Hynes は、マイクロソフトの Enterprise and Partner (EPG) グループの Enterprise Technology Strategist で、セキュリティ機能とセキュリティ製品を専門に扱っています。EPG の前は、2005 年から Windows Server 部門のメンバとして、BitLocker (System Integrity) チームと密接に協力して業務に取り組んでいました。皆さんのご意見やご質問をお待ちしています。Tech•Ed 2008 で声をかけていただくか、bhynes@microsoft.com (英語のみ) まで電子メールをお送りください。


セキュリティ
ソフトウェア制限ポリシーを使用したアプリケーションのロックダウン
Chris Corio and Durga Prasad Sayana
概要:
  • ソフトウェア制限ポリシーのしくみ
  • 環境内にあるアプリケーションの一覧を作成する
  • ポリシーを作成および適用する

IT プロフェッショナルが、デスクトップ コンピュータの総保有コスト (TCO) を削減しようとするとき、思い浮かぶ主な戦略は 2 つあります。1 つは、デスクトップ ユーザーの
アカウントを Administrators グループから除外することです。2 つ目は、ユーザーが実行できるアプリケーションを制限することです。企業環境でこれらの問題に取り組むことは、非常に困難な作業になる可能性がありますが、Windows Vista® では、この目標の達成に役立つテクノロジがいくつか提供されています。
Windows Vista とそのユーザー アカウント制御 (UAC) 機能により、かなり容易に企業ユーザーを Users グループのメンバ (標準ユーザー) として実行できるようになりました。UAC によって、すべてのアプリケーションの既定のセキュリティ コンテキストが、管理者ではなくユーザーのセキュリティ コンテキストに変更されました。それでも依然として、この Users グループへの移行は大変な作業ですが、業界がこの新しいパラダイムに歩調を合わせていくに従って、今よりも容易な作業になっていくでしょう。
多くの管理者は、Users グループへのユーザーの移行に伴う課題の分析を終えたときや、場合によっては分析中に、ユーザーが実行する必要があるアプリケーションを洗い出し、これらのアプリケーションのみを許可するための手順を検討します。ソフトウェア制限ポリシー機能は、まさにこの作業を支援することを目的としています。
この作業を完了するには、グループ ポリシーを使用して、実行を許可するアプリケーションを指定し、そのポリシーを展開するだけです。このようなグループ ポリシーを全社に適用することで、サポートされないアプリケーションに関する問題が制限されるため、TCO を削減できます (ソフトウェア制限ポリシーは、補足記事「必要最小限のソフトウェア制限ポリシー」で説明するような、魅力的かつ非常に極端な方法で使用することもできます)。

ソフトウェア制限ポリシーのしくみ
ソフトウェア制限ポリシーは、Windows Vista コンピュータ上でユーザーが実行できるコードを正確に制御することを目的としています。管理者は、環境内で実行できる (またはできない) アプリケーションを定義するポリシーを作成します。このポリシーは、どのような場所でコードが実行される場合でも常に評価されます。たとえば、プロセスの作成時、ShellExecute の呼び出し時、スクリプトの実行時などが考えられます (これについては、この後詳しく説明します)。
実行を許可されているアプリケーションと判断された場合、アプリケーションは起動しますが、実行を許可されていないアプリケーションと判断された場合、アプリケーションはブロックされ、ユーザーにそのことが通知されます。たとえば、[スタート] メニューからソリティアを実行しようとして、これが許可されていないアプリケーションであった場合、図 1 のようなダイアログ ボックスが表示されます。
図 1 アプリケーションがブロックされたときに表示されるダイアログ ボックス
図 1 アプリケーションがブロックされたときに表示されるダイアログ ボックス (画像を拡大するには、ここをクリックします)
ソフトウェア制限ポリシーを定義する UI は、グループ ポリシー オブジェクト エディタ (GPOE) からアクセスでき、これを使用してロックダウン ポリシーを作成します。実行を許可または拒否するコードを定義するときは、さまざまな方法を使用できます。ポリシーが完成し、テストが完了したら、そのポリシーを展開できます。

ソフトウェア制限ポリシーを定義する
まず決定しなければならない大切なことは、既定の規則の種類を選択することです。この決定は、ソフトウェア制限ポリシーが環境内でどのように機能するかについて非常に大きな影響を及ぼします。ソフトウェア制限ポリシーは、許可リストと拒否リストという 2 種類のモードのいずれかで展開できます。基本的に、環境内で実行を許可するすべてのアプリケーションを指定するポリシーを作成するか、実行できないすべてのアプリケーションを定義するポリシーを作成します。
許可リスト モードでは、ポリシー内の既定の規則は [Restricted] (制限する) で、実行を明示的に許可していないアプリケーションがすべてブロックされます。拒否リスト モードでは、既定の規則は [Unrestricted] (制限しない) で、明示的に指定したアプリケーションのみが制限されます。
拒否リスト モードは、ご想像のとおり、TCO の大幅な削減と、アプリケーションのロックダウンによるセキュリティ上のメリットを求めている場合には、非現実的な方法です。すべてのマルウェアやその他の問題のあるアプリケーションをブロックする膨大な一覧を作成し、それを保守することは不可能に近いため、ソフトウェア制限ポリシーは、既定の規則が [Restricted] (制限する) である許可リスト モードで実装することをお勧めします。

環境内にあるアプリケーションの一覧を作成する
実行できるアプリケーションを指定するポリシーを設計する場合は、ユーザーが必要とするアプリケーションを正確に特定する必要があります。ソフトウェア制限ポリシー機能では、詳細ログ機能と、環境内で実行されるアプリケーションを正確に把握できる非常に簡潔なポリシーが提供されます。
環境内にあるコンピュータのサンプル グループを対象に、既定の規則を [Unrestricted] (制限しない) に設定し、その他の規則を削除して、ソフトウェア制限ポリシーを展開します。この目的は、ソフトウェア制限ポリシーを有効にする一方で、アプリケーションは制限されないようにすることによって、実行されようとするアプリケーションのみを監視できるようにすることです。
次に、以下のレジストリ値を作成することによって、詳細ログ機能を有効にし、ログを書き込むファイルのパスを設定します。
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>
これで、アプリケーションが実行され、ソフトウェア制限ポリシーが評価される (すべてのアプリケーションの実行を許可している場合でも、ポリシーは評価されます) ときに、ログ ファイルにエントリが書き込まれるようになります。
各ログ エントリには、ソフトウェア制限ポリシーの呼び出し元、呼び出し元プロセスのプロセス ID (PID)、評価されるアプリケーション、該当するソフトウェア制限ポリシーの規則の種類、およびその規則の識別子に関する情報が含まれます。以下は、ユーザーが notepad.exe をダブルクリックしたときに書き込まれるエントリの例です。
explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}
このログ ファイルは、ソフトウェア制限ポリシーが有効になっており、アプリケーションをブロックするように設定されているときに、そのポリシーによって確認されるすべての実行可能コードを表します。したがって、ログ ファイルのエントリごとに、そのコードを許可リスト内に含めるかどうかを判断する必要があります。システムが機能するために必要な、Windows® を構成しているいくつかのバイナリが確認されることに注意してください。
ログを使用したこの手法によって、環境内でソフトウェア制限ポリシーによって検出されるアプリケーションを正確かつ容易に把握できますが、これ以外にも方法はあります。
Microsoft® Application Compatibility Toolkit 5.0 に含まれているインベントリ コレクタを使用すると、環境内で使用されているアプリケーションの一覧を作成できます。このツールでは、さまざまな方法を使用して、環境内にインストールされているアプリケーションを検出し、結果を集中管理用のデータベースに統合できます。

追加の規則を作成する
環境内で実行を許可するアプリケーションの一覧を作成したら、これらのアプリケーションの実行を許可する実際の規則を作成できます。ソフトウェア制限ポリシー機能では、2 とおりの方法でポリシーを指定します。1 つは、アプリケーションの暗号化プロパティ (ハッシュなど) に基づいており、もう 1 つは、信頼されたアプリケーションが格納されている信頼済みパスまたはフォルダを定義します。
図 2 は、GPOE (gpedit.msc) の [ソフトウェアの制限のポリシー] ノードで、アプリケーションの実行を許可する規則を追加する場所を示しています。環境内のアプリケーションを定義する最も簡単な方法は、ログを使用する先ほどのプロセスで検出できたすべてのバイナリに対応するハッシュの規則を作成することです。
図 2 gpedit.msc を使用したソフトウェア制限ポリシーの作成
図 2 gpedit.msc を使用したソフトウェア制限ポリシーの作成 (画像を拡大するには、ここをクリックします)
ハッシュは、特定のビット セットに対して返される一意の値であるため、ポリシー内の各バイナリには異なるハッシュが割り当てられます。これは特に強固なセキュリティが提供される方法であり、ポリシー内で指定された特定のバイナリのみが実行を許可されます。
もちろん、この方法には欠点もいくつかあります。たとえば、環境内には少なくとも数千個のバイナリが存在します。規則の数が膨大になると、パフォーマンスに影響する可能性があるため、ソフトウェア制限ポリシーの UI からこれらのバイナリに対応する規則をすべて作成することは困難です。また、環境内のアプリケーションに適用するそれぞれの更新プログラムを環境内に展開するには、新たに 1 つ以上のハッシュの規則が必要になります。アプリケーションの更新に合わせてこのような大規模なポリシーを更新することは、非常に面倒な作業になる可能性があります。
さいわい、その他にも規則を指定する方法は 2 つあり、これらを使用することによって、環境内でソフトウェア制限ポリシーをより容易に使用できるため、この面倒は避けることができます。暗号化セキュリティを利用すると、特定の証明書によって署名されたバイナリの実行を許可する規則を作成できます。
これにより、アプリケーションの更新時に、新しいバイナリが基本的に前と同じ証明書によって署名されるため、ポリシーの一覧を容易に保守できるようになります。ただし、バイナリの以前のバージョンを環境内で実行しない場合は、実行を制限するハッシュの規則を追加して、このファイルの実行が許可されないようにします。
ソフトウェア制限ポリシーでは、証明書の規則の評価が既定で無効になっています。これには 2 つの理由があります。
1 つ目の理由は、ソフトウェア制限ポリシーに含まれる証明書の規則が、システム上の信頼された発行元のストアに格納されている証明書によって定義されるためです。信頼された発行元のストアは、ソフトウェア制限ポリシーの規則以外の目的でも使用されるため、このストアをソフトウェア制限ポリシー機能に使用する場合は、より時間をかけて入念に検討する必要があります。
2 つ目の理由は、ファイルのハッシュを取得し、これを署名情報と比較して、ファイルの署名が有効であるかどうかを判断する必要があるためです。ファイルのハッシュの作成は、処理コストが非常に高い操作です。これを行うには、ファイル全体をディスクから読み取り、ハッシュを計算する必要があります。
証明書の規則を有効にするには、[ソフトウェアの制限のポリシー] ノードを参照し、結果ウィンドウ内の [強制] オブジェクトを選択します。これをダブルクリックしてプロパティ ダイアログ ボックスを開き、証明書の規則を適用するためのオプションを選択します。
コードを指定するもう 1 つの一般的な方法は、ローカル コンピュータ上のコードのパスを使用する方法です。これは、効率的で効果的な手法ですが、1 つ欠点があります。それは、セキュリティ設定が目的のフォルダに適切に設定されるよう十分に注意しなければならないことです。
特定のパスの規則を追加し、ユーザーにこのパス (デスクトップなど) へのファイルの書き込みを許可すると、ユーザーはこのフォルダに実行可能ファイルを保存するだけで、任意のファイルを実行できるようになります。ただし、Administrators グループに属していないユーザーは、通常、Program Files または Windows ディレクトリ内のファイルを変更できません。このため、すべてのアプリケーションが Program Files ディレクトリ内にあり、ユーザーが Administrators グループに属していない場合は、パスの規則を使用して、非常に単純で効率的なポリシーを作成するとよいでしょう。
パスの規則では、他にも一部の環境に適した機能が提供されます。この規則では、ワイルドカードや環境変数を使用して、環境内の別の場所でも使用できる規則を容易に定義できます。たとえば、%systemdrive% はユーザーによっては c:\ ではない可能性があるため、この機能は便利です。
パフォーマンスと保守性を考えると、おそらくこれが最も手間をかけずにコードを指定できる方法と言えるでしょう。このパスの規則は当然使用を検討する必要がありますが、セキュリティに関するその他の考慮事項にも留意する必要があります。

ネットワーク ゾーンの規則
ソフトウェア制限ポリシーには、"ネットワーク ゾーンの規則" も含まれていますが、この規則は廃止される予定です。この規則はもともと、ある実行可能コードの提供元を特定して信頼し、その結果として、コードの実行を許可することを目的としていました。残念ながら、これは実現が非常に難しく、あまり有効に機能しませんでした。現在、この規則は、ほとんどのソフトウェア制限ポリシーのエントリ ポイントで適用されていません。
ほとんどのアプリケーションが %Program Files% ディレクトリにインストールされる場合でも、異なる場所に他の実行可能ファイルがインストールされ、それらが特定の証明書によって署名される場合は、別の種類の規則を使用したほうがよいでしょう。いくつかのハッシュの規則とパスの規則を使用すると、各環境に最適なポリシーを構成できます。
ただし、規則の処理順序が存在することに注意してください (図 3 参照)。まず証明書の規則が最も厳密で、次にハッシュの規則、パスの規則、ワイルドカードを含むパスの規則と続きます。したがって、コードがハッシュの規則とパスの規則によって指定されている場合は、ハッシュの規則のセキュリティ レベルが優先されます。
図 3 規則の処理順序
図 3 規則の処理順序 (画像を拡大するには、ここをクリックします)

ポリシーの適用
ソフトウェア制限ポリシー機能では、システム内のある一定の範囲に対してセキュリティ保護が提供されます。つまり、コードを実行できる場所にソフトウェア制限ポリシーが統合されるため、ポリシーを確認することによって、実行可能コードの実行を許可するかどうかが判断されます。
ソフトウェア制限ポリシーが確認される場所は多数ありますが、最もわかりやすいエントリ ポイントは CreateProcess です。CreateProcess の処理中に、ポリシーが確認され、該当するアプリケーションを表すバイナリの実行を許可するかどうかが判断されます。ポリシーの確認は SaferIdentifyLevel API (この API のドキュメントは公開されています) によって実行されます。一般的なプロセスについては、図 4 を参照してください (SaferIdentifyLevel については、この後すぐに説明します)。
図 4 バイナリが実行可能かどうかを SaferIdentifyLevel によって判断する
図 4 バイナリが実行可能かどうかを SaferIdentifyLevel によって判断する (画像を拡大するには、ここをクリックします)
ソフトウェア制限ポリシーが適用される API のうち、CreateProcess の次によく使用される API は ShellExecute です。この API は、[スタート] メニューに列挙されているアプリケーションをクリックするか、デスクトップ上のなんらかのオブジェクトをダブルクリックしたときに呼び出されます。
ShellExecute はさまざまなファイル形式に対して呼び出すことができます。たとえば、.txt ファイルに対して ShellExecute を呼び出しても、実際にこのファイルは実行されませんが、もちろん技術的には開かれます。このため、ソフトウェア制限ポリシーには、実行可能なファイルの種類の一覧が含まれており、この一覧によって、ShellExecute の呼び出し時に確認するファイルの種類が制御されます。この実行可能ファイルの種類の一覧は、ソフトウェア制限ポリシーの UI からカスタマイズできます。
CreateProcess と ShellExecute 以外では、他に 2 つ、ソフトウェア制限ポリシーが統合された重要なエントリ ポイントがあります。これらは、LoadLibrary とスクリプト ホストです。LoadLibrary が実行可能コードを確認する重要な場所であることは明らかですが、残念ながら LoadLibrary にはいくつか特殊な制限があります。
ほとんどのアプリケーションは、1 つの実行可能ファイルと、読み込まれる複数の DLL から構成されています。また、通常は、システム上で多数のアプリケーションが実行されます。したがって、LoadLibrary では、かなりの数のポリシーの確認が必要になります。このため、コードを指定するポリシーによっては、ポリシーが適用されるエントリ ポイントとしての LoadLibrary の処理コストは非常に高くなる可能性があります。システムに読み込まれるすべての DLL のハッシュを確認する必要があるため、それらのバイナリに対応するハッシュを作成し、作成したハッシュをおそらく数千のハッシュと比較することになります。
この機能は、既定では無効になっていますが、手動で有効にできます。これを行うには、gpedit.msc で [ソフトウェアの制限のポリシー] ノードを参照し、[強制] をダブルクリックして、[ソフトウェアのファイルすべて] を選択します。
前述のとおり、ソフトウェア制限ポリシーは、システム内のほとんどのスクリプト ホストに統合されます。これに該当するのは、cmd、VBScript、Cscript、JScript® などです。これらを始めとするエントリ ポイントでは、最も重要なソフトウェア制限ポリシー API である SaferIdentifyLevel が使用されます。
SaferIdentifyLevel API は、関連するソフトウェア制限ポリシー内の ID 情報を参照することによって、指定された実行可能ファイルの実行を許可するかどうかを決定します。この API のドキュメントは公開されています。サードパーティ製のスクリプト ホストや実行可能環境でも、この API を使用してソフトウェア制限ポリシーを統合できます。これによって、ポリシーを使用して実行可能コードの実行を許可するかどうかを決定できるようになります (この方法は推奨されています)。

標準ユーザーとして実行する
あまり知られていないソフトウェア制限ポリシーの機能の 1 つに、特定のアプリケーションの特権をアプリケーションの起動時にフィルタ選択できる機能があります。これは Windows XP で導入された機能ですが、Windows Vista で初めて、ソフトウェア制限ポリシーの UI に含まれました。
この機能は、Windows Vista UAC の前身であると言えます。その理由は、この機能を使用すると、ユーザーが Administrators グループに属している場合でも、標準ユーザーとしてアプリケーションを実行できたためです。この動作は、追加の規則を作成する UI から規則を作成し、そのセキュリティ レベルを通常ユーザーに設定した場合と同じ動作です。
UAC のトークン フィルタ機能と、ソフトウェア制限ポリシーの通常ユーザーの規則は、どちらも CreateRestrictedToken API と同じ動作が実装された API を基盤として活用しています。ただし、これらのテクノロジの全体的なアーキテクチャは大きく異なります。UAC は、主に次のような点でソフトウェア制限ポリシーと異なります。
まず、Windows Vista で UAC が有効になっている場合、ユーザーが管理者であったとしても、すべてのアプリケーションは、既定で Users グループのメンバと類似したセキュリティ トークンを使用して起動します。この動作はソフトウェア制限ポリシーを使用しても実現できますが、たとえば、ユーザーがアプリケーションをインストールする必要がある場合、ユーザーの実際の管理者トークンを使用してアプリケーションを起動する手段はありません。既定のセキュリティ コンテキストを変更し、ユーザーの完全な管理者トークンを容易に利用できることは、UAC の重要な利点です。
2 つ目の違いは、実行可能ファイルを処理する場合、コード自体が、動作するために必要な特権レベルを通知することです。これによって、独立系ソフトウェア ベンダ (ISV) や開発者はコードの要件を把握できるため、これは重要な違いであると言えます。たとえば、コントロール パネル アプリケーションで、あるオブジェクトを編集するために管理者特権が必要である場合、この要件をマニフェスト内に指定できます。したがって、ISV は、アプリケーションに必要な特権を記述できるため、特権レベルを変更する手段を提供できずに、ある特権レベルをアプリケーションに強制する必要はありません。
当面は、動作を十分に理解するまで、通常ユーザーの規則を使用しないことをお勧めします。UAC は、Administrators グループからデスクトップ ユーザーを移行するときに非常に役立ちます。企業環境への UAC の実装を真剣に検討してみてください。

ソフトウェア制限ポリシーの現状
どのような状況でソフトウェア制限ポリシーを使用するかを判断する必要がある場面は、数多く想定できます。ただし、実際は想像するほどそのような場面に遭遇することはなく、現在も気付かないうちにソフトウェア制限ポリシーを使用している可能性があります。たとえば Windows Vista システムで保護者による制限機能を実行していれば、ソフトウェア制限ポリシーを使用してアプリケーションの実行を制御していることになります。
ソフトウェア制限ポリシーは、Windows XP で初めて導入された、重要な技術上の進歩です。ただし、アプリケーションのロックダウンが IT プロフェッショナルの注意を引き始めたのは、ごく最近のことです。
Windows Vista のソフトウェア制限ポリシー機能は、まだ改善の余地がありますが、環境内でどのソフトウェアの実行を許可するかをこれまでよりも容易に制御できるため、この機能を使用することをお勧めします。さいわい、このテクノロジは今後も進化し続け、システムの管理だけでなく、Microsoft Windows 環境の運用にかかるコストの削減にも役立つテクノロジとなることが予想されます。
必要最小限のソフトウェア制限ポリシー
ソフトウェア制限ポリシーの利用方法の 1 つとして、Windows をキオスク モードにロックダウンするポリシーの作成が挙げられます。マイクロソフトは、このキオスクを作成するためのツールキットである SteadyState™ を実際に作成しました。ただし、実行可能なアプリケーションのロックダウンのみを行う場合は、これよりも単純な方法を使用できます。
Windows Vista へのログオンに最低限必要なアプリケーションの実行を許可するには、%windir%\system32 からの logonui.exe と userinit.exe の実行を許可するポリシーを作成します。また、大部分のユーザーのために、次のアプリケーションの実行も許可する必要があります。
dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....
既定の Windows シェルが必要である場合は、%windir%\explorer.exe も追加します。
また、Internet Explorer® など、特定のアプリケーションを直接起動することもできます。その場合は、explorer.exe ではなく、iexplore.exe を一覧に追加します。
この必要最小限のポリシーのもう 1 つの特徴は、ユーザーが Administrators グループに属していないことを前提としていることです。ユーザーが Administrators グループに属している場合、ポリシーが回避される可能性があるため、この点を認識しておくことは重要です。このポリシーが適用された場合、ユーザーはごく基本的なアプリケーションしか実行できず、管理者の特権も与えられないため、アプリケーションをインストールしたり、システムを保守したりすることはできません。
必要最小限のポリシーを適用したコンピュータ上でこのような作業を実行する場合、なんらかの方法が必要になるでしょう。管理者アカウントを使用してローカルにログオンすることで、このようなコンピュータの更新と保守を行う場合は、ソフトウェア制限ポリシーをローカル管理者以外のすべてのユーザーに適用するオプションを選択します。また、ポリシーに consent.exe と cmd.exe も含めるようにします。これによって管理者は、管理者用のコマンド プロンプトから任意の管理操作を実行できるようになります。
UAC は、トークンが Administrators グループに属していないかのように扱うことで、ユーザーのセキュリティ トークンの特権を制限します。上記の設定を行って管理者にポリシーを適用しないようにしても、ユーザーにはポリシーが適用されます。UAC の昇格を行った場合のみ、管理者に完全な管理者特権が与えられ、ソフトウェア制限ポリシーの適用対象から除外されます。

Chris Corio は、5 年以上にわたりマイクロソフトの Windows セキュリティ チームに所属していました。マイクロソフトでは、主にアプリケーションのセキュリティに関するテクノロジと、Windows をセキュリティで保護するための管理テクノロジを担当していました。連絡先は winsecurity@chriscorio.com (英語のみ) です。
Durga Prasad Sayana は、Windows コア セキュリティ チームのソフトウェア デザイン エンジニア兼テスト担当者です。セキュリティに関するテクノロジとソフトウェア テストを専門に扱っています。連絡先は durgas@microsoft.com (英語のみ) です。


セキュリティ
Windows Vista のファイアウォールを管理する
Jesper M. Johansson
概要:
  • 規則の種類とシナリオ
  • ファイアウォールのプロファイル
  • ドメインの分離の規則
  • 送信フィルタの問題

少し前に、私は自分のブログで Windows Vista のファイアウォールについての記事を書きました。そこでは、単にいくつかの便利な機能を紹介しただけで、展開上のアドバイスについてはあまり触れていませんでした。
この記事では、特にエンタープライズ管理を支援する Windows Vista® のファイアウォール機能の一部について詳しく説明します。また、管理作業を簡素化し、セキュリティを強化するうえで、これらの機能をどのように使用できるかについてのアドバイスも提供します。
最近リリースされた Windows Vista SP1 によって、皆さんは Windows Vista のエンタープライズ展開が進むと思われているかもしれません (企業では、最初のサービス パックがリリースされるまで、新しい OS への移行を控えるというのが一般的です)。現在、エンタープライズ環境への Windows Vista の導入について真剣に検討し始めている IT プロフェッショナルの方には、ファイアウォールの詳細を確認することをお勧めします。Windows Vista のファイアウォールの機能を理解すると、サードパーティ製のセキュリティ スイートの契約内容を見直して、ファイアウォールを契約から外したくなるかもしれません。

Windows ファイアウォールの過去と現在
Windows® XP の最初のリリースで提供されたファイアウォールは、多くの課題を抱えていました。当時市販されているホスト ベースのファイアウォールとは十分に渡り合えるセキュリティ機能は備えていましたが、新機能や革新的な機能は追加されていませんでした。
Windows XP SP2 で提供された後継バージョンは、抜本的に変更されました。このバージョンは、特にエンタープライズ管理が容易になるよう設計されていました。Windows XP SP2 のファイアウォールは、軽量、一元管理が可能、有効、干渉が少ないという特質を備えた、非常に魅力的なファイアウォールです。しかし、おそらく最も重要なことは、Windows XP SP2 のファイアウォールでは、起動時にシステムの保護という非常に重要な処理が行われることです。
この最後の点は、きわめて重要です。ファイアウォールが有効になっていても、起動時にマルウェアに感染してしまうシステムは少なくありませんでした。実際、Blaster が最も猛威を振るった期間の感染率は、4 分に 1 台という非常に高いものでした。つまり、保護されていないコンピュータをインターネットに接続した場合、そのコンピュータは平均して 4 分後にウイルスに感染する可能性があったということです。また、起動時にシステムを保護しないファイアウォールを利用していた場合、12 個のシステムにつき 1 つが再起動時に感染していた可能性がありました。このようなデータを踏まえて、Windows XP SP2 のファイアウォールでは起動時にシステムを保護するようになりました。
Windows Vista では、再びファイアウォールの抜本的な変更が行われました。最も顕著な管理上の変更は、インターネット プロトコル セキュリティ (IPsec) とファイアウォールの管理インターフェイスが統合されたことです。これは非常に理にかなった変更です。IPsec とファイアウォールは、どちらも許可されていないものをブロックすることを目的としています。違いは、ファイアウォールで許可しない対象を定義するパラメータでは、あまり詳細な設定ができず、IPsec では広い範囲のアドレス空間をブロックまたは許可するのが困難なことです。
これら 2 つの機能を 1 つの管理インターフェイスにまとめることで、管理者は、両方のテクノロジをシームレスに使用でき、IPsec の規則が必要なのか、ファイアウォール フィルタを使用すべきかについて、これまでほど悩まずに済みます。つまり、システムがネットワーク攻撃を受ける可能性のある領域を一元的に管理できるので、ミスを最小限に抑えるうえで有効です。
Windows Vista SP1 のファイアウォールでは、信頼性が強化されました。また、IPsec に新しいアルゴリズム (Suite B アルゴリズム) を採用しています。これは、暗号化関連のアルゴリズムで、AES (Advanced Encryption System)、楕円曲線暗号化 (ECC)、セキュア ハッシュ アルゴリズム (SHA) 256 および 384 で構成されています。
しかし、最も重要なのは、Windows Vista Service Pack 1 でネットワーク アクセス保護 (NAP) のサポートが追加されたことです。NAP は、侵害されていない管理クライアントであっても、最新のセキュリティ ポリシー、更新プログラム、マルウェア対策定義に準拠している状態でなければ、ネットワークへの接続を許可しないポリシー強制ツールです。NAP では悪意のあるホストがネットワークに接続することは阻止できませんが、すべての管理ホストが、侵害されていない限り、完全にポリシーに準拠していることを保証できます。
Windows Vista のファイアウォールは、"セキュリティが強化された Windows ファイアウォール" と呼ばれ、Windows Server® 2008 にも搭載されています。すべての機能をリモートからも管理できるだけでなく、グループ ポリシーを使用してネットワーク レベルで構成できます。

規則の種類とシナリオ
1 つの管理インターフェイスにファイアウォールと IPsec の機能が統合されたため、"方向の規則" および "接続の規則" という 2 種類の規則が使用されるようになりました。方向の規則は標準のファイアウォールの規則で、方向ごとに許可するトラフィックを定義します。接続の規則は、コンピュータ間の接続の保護パラメータを定義します。たとえて言うと、方向の規則は以前のファイアウォールでお馴染みのファイアウォールの規則にやや似ています。また、接続の規則は、Windows XP SP2 のファイアウォールと連携して使用していた IPsec の規則に似ています。
ファイアウォールと IPsec を同じインターフェイスに統合することで、いくつか非常に興味深いシナリオが可能になります。たとえば、ネットワーク上でシステムを互いに分離することは、現在最も有用なセキュリティ概念の 1 つです。マイクロソフトでは、これを "サーバーとドメインの分離" と呼んでいます。
サーバーとドメインの分離では、IPsec とファイアウォールの両方の機能を使用します。これを踏まえて、この新しいファイアウォール管理インターフェイスには、分離の規則用の機能が実装されています。この規則は、たとえば接続元または接続先のシステムの属性 (ドメイン メンバシップなど) を基に接続を制限する場合に適しています。
新規の接続セキュリティの規則ウィザードでは、まず作成する規則の種類を指定します (図 1 参照)。[分離] を選択すると、分離の規則に適した特定の設定が自動的に構成されます。
図 1 新規の接続セキュリティの規則ウィザードを使用した分離規則の作成
図 1 新規の接続セキュリティの規則ウィザードを使用した分離規則の作成 (画像を拡大するには、ここをクリックします)
また、図 1 を見ると、分離の規則の説明で正常性の状態に触れています。サーバーとドメインの分離に使用される規則は、実は NAP に使用する規則と同じです。
トラフィックの種類によっては、認証を強制できないものがあります。たとえば、DNS 解決では認証を要求するのは望ましくないでしょう。この種類のトラフィックのエンドポイントには、認証の除外規則が必要です。認証の除外規則では、文字どおり、IPsec 要件から特定のトラフィックを除外します。
サーバー間の規則は、少し不適切な名前です。一般的にはサーバーで使用されるものですが、クライアントにも使用できます。サーバー間の規則は、単に認証を要求するように接続を構成するものです。分離の規則は認証を要求するだけでなく、ドメイン メンバシップや正常性の状態など他の条件を満たすことも要件になる点で、サーバー間の規則とは異なります。
トンネル規則では、基本的にサイト間の仮想プライベート ネットワーク (VPN) と、ゲートウェイ間のトンネルを定義します。ただし、Windows Vista がゲートウェイ機能に使用される可能性は低いので、トンネル規則を Windows Vista で使用することはまれです。完全にカスタマイズした規則を作成できるため、規則のすべてのパラメータをカスタマイズできます。

規則の順序
規則の順序は、一見少し複雑です。規則の順序を理解する鍵は、まず順序について忘れることです。問題なのは順序ではなく、どの規則に一致するかです。受信トラフィックを例に考えてみましょう。既定では、受信トラフィックは、そのトラフィックを許可する規則がない場合、ブロックされます。"許可規則を最初に考慮する" という順序を使用することを考えるかもしれませんが、この考えは適切ではありません。あるパケットが許可規則とブロック規則の両方に一致する場合、ブロック規則が適用されます。つまり、一致した場合の動作を簡単にまとめると次のようになります。
  1. ブロック規則 : パケットまたは接続がこの規則に一致すると、破棄されます。
  2. 許可規則 : パケットまたは接続がこの規則に一致すると、許可されます。
  3. 既定の方向のプロファイルの動作 : どのブロック規則と許可規則にも一致しない場合、トラフィックは、そのプロファイルの該当方向のトラフィックで、既定として指定されている動作に従って処理されます。すべてのプロファイルの既定の構成では、受信方向のトラフィックはブロックされます。送信方向の場合、既定の構成ではトラフィックが許可されます。
照合プロセスは、認証済みバイパス (IPsec) 規則によって調整されます。この規則を使用すると、この規則の他のパラメータに一致するすべての認証済みトラフィックが、他の規則に一致するかどうかに関係なく、許可されます。認証済みバイパス規則は、[ブロックの規則より優先する] チェック ボックスがオンになっている方向の規則です (図 2 参照)。この規則は、認証済みトラフィックが必ずシステムにアクセスできるように、最初に考慮されます。これにより、簡単に認証済みホストからのトラフィックを許可し、他のコンピュータからのトラフィックをブロックすることができます。このルールの順序は 0 番であると考えることができます。したがって、完全な規則の順序は、次のようになります。
図 2 認証済みバイパス規則を構成するには、[ブロックの規則より優先する] チェック ボックスをオンにする
図 2 認証済みバイパス規則を構成するには、[ブロックの規則より優先する] チェック ボックスをオンにする (画像を拡大するには、ここをクリックします)

0. 認証済みバイパス規則
1. ブロック規則
2. 許可規則
3. 既定の方向のプロファイルの動作

トラフィック パターンに一致する規則が各クラス内に複数あるかどうかは、それほど問題ではありません。いずれかの規則がトラフィックに一致した時点で、規則の処理は停止します。

パブリック、プライベート、およびドメイン
ネットワークの関連情報
  • TechNet セキュリティ センター
  • Netsh Advfirewall コマンドライン ツールを使用する
  • Windows Vista および Windows Server 2008 における Windows ファイアウォール セキュリティの規則と IPSec ベースの接続セキュリティの規則
  • セキュリティ ウォッチ : Windows Server 2008 で SCW を使用する

新しいファイアウォールには、パブリック、プライベート、およびドメインという 3 種類のプロファイルがあります。一方、Windows XP SP2 のファイアウォールのネットワーク プロファイルは 2 種類で、標準とドメインでした。ドメイン プロファイルは、コンピュータでドメイン コントローラが検出された場合、自動的に呼び出されます。Windows XP では、ドメインが検出できなかった場合には標準プロファイルが使用されました。これはセキュリティ管理者にとって強力な機能を提供し、コンピュータの移動中 (ローミング中) にはコンピュータを完全にロックダウンし、組織のネットワーク上にあるときは必要なリモート管理機能のすべてを利用できるようにすることができました。しかし、この方法は、一部のユーザー (特に自宅で個人のネットワークを構築しているユーザー) にとって問題がありました。システムがドメイン コントローラにアクセスできない場合には標準プロファイルが使用されたため、ユーザーが自宅でシステムを使用するときにはシステムがロック ダウンされてしまいました。
Windows Vista で導入された新しいプライベート プロファイルは、この問題を解決するのに役立ちます。システムを新しいネットワークに接続すると、ネットワークがパブリック (以前の標準プロファイルに付けられた新しい名前です) であるかプライベートであるかが確認され、システムが適切に構成されるようになりました。システムは、特定のネットワークに接続するたびに、ネットワークのインフラストラクチャ サーバーから提供されたネットワーク パラメータに基づいて適切な構成を適用します。これは完璧な対策ではありませんが、より多くのネットワークをより適切にロック ダウンできるという点で有用です。
システムがドメイン上にあるかどうかを検出するロジックも強化されています。その結果、より早く、かつ安定したネットワークの切り替えが実現され、実際にドメイン上にあるにもかかわらず、パブリック プロファイルやプライベート プロファイルを使用するという誤った判断をするシステムが少なくなりました。
規則を特定の種類のネットワークに関連付けて、システムが不要に情報を公開したり、信頼されていないネットワーク上のシステムに接続することを防止できます。これは、ファイアウォールと IPsec の統合が本領を発揮できる領域の 1 つです。
このような新しい規則を使用すると、これまでは不可能だったいくつかの制限を実現できます。たとえば、これまで長年にわたって、(Windows ネットワークの場合) 信頼されていないホストへのサーバー メッセージ ブロック (SMB) 接続を確立するようユーザーを誘導する攻撃が仕掛けられてきました。攻撃者は、このような接続をユーザーに確立させて、パスワードの解読に使用できるチャレンジ/レスポンス ペアを提供する認証シーケンスを強制的に実行していました。この攻撃は古くは、クリア テキスト認証へのダウングレードや、ユーザーのチャレンジ/レスポンス ペアを接続元のコンピュータに渡す手段としても使われていました。前者の手法については、かなり前に防止策が確立されました。後者の手法については、Windows XP SP2 で対応していますが、チャレンジ/レスポンス ペアを自発的に提供することは、やはり賢明ではありません。
これを防ぐには、Windows Vista のファイアウォールで導入された新機能である送信フィルタを使用できます。たとえば、パブリック プロファイルのすべての送信 SMB 接続 (TCP ポート 135、139、445、および UDP ポート 137、138、445 が宛先である接続) をブロックできます。この機能を使用すると、チャレンジ/レスポンス ペアの取得を図る誘導攻撃でシステムが悪用されにくくなるだけでなく、インターネット上の信頼されていない Windows ファイル共有へのアクセスを防止できます。
ただし、やはり、これも完璧な対策ではありません。たとえば、システムが既に侵害されている場合、攻撃者がこの規則を無効にできるため、この規則によってシステムの通信を阻止することはできません。しかし、これは、動作は適切でも攻撃を受ける可能性があるシステムの保護対策としては非常に有用な場合があります。
Windows XP SP2 と同様に、Windows Vista と Windows Server 2008 でも、一度にアクティブにできるプロファイルは 1 つだけであることを指摘しておきます。システムで 2 つのネットワーク インターフェイスが有効になっていて、そのうちの 1 つがドメインに接続し、もう 1 つがパブリック ネットワークに接続している場合、パブリック ファイアウォール プロファイルが両方のインターフェイスに適用されます。常に最も制限の厳しいプロファイルが使用されます。ご想像のとおり、パブリック プロファイルはプライベート プロファイルより、プライベート プロファイルはドメイン プロファイルよりも厳しい制限を適用します。ですから、送信 SMB ブロック規則を使用すると、VPN 接続上の大半のトラフィックが阻止される可能性があることに注意してください。
コンピュータがパブリック ネットワークまたはプライベート ネットワーク上にあるときに、VPN 接続経由のトラフィックを可能にするには、VPN インターフェイスにのみ適用する方向の規則を作成します。これが機能するには、VPN インターフェイスが Windows で VPN インターフェイスとして認識される必要があります。Microsoft® ルーティングとリモート アクセス サービス VPN サーバーを使用していない場合は、この機能を大々的に展開する前にテストを行ってください。これは基本的に、クライアントへの受信トラフィックとカスタムの送信規則との問題です。

ファイアウォール規則を作成する
新しいファイアウォールでは、ファイアウォール規則を格段に簡単に作成できるようになりました。新しい規則ウィザード (図 3) を使用して、一般的な種類の規則を定義できます。また、特定のサービス用の定義済みの規則も用意されています。
図 3 新しい規則ウィザードの定義済みの規則
図 3 新しい規則ウィザードの定義済みの規則 (画像を拡大するには、ここをクリックします)
定義済みの規則は特に重要です。基本的に、サーバーの分離は、サービスを使用する必要があるシステムにのみ、当該サービスが提供されるように制限することを目的としています。完全に面倒な設定がなくなるわけではありませんが、サーバー製品では、Windows セキュリティの構成ウィザード (SCW) を使用して、この構成を簡単に行うことができます (SCW については、2008 年 3 月号の TechNet Magazine を参照してください)。
しかし、Windows のクライアント製品には、これまで同様の機能がありませんでした。定義済みの規則を使用すると、面倒な作業の大半 (つまりサービスが使用するエンドポイントを特定する作業) は、自動的に行われます。ファイアウォールはアプリケーションを識別できるだけでなく (たとえば、"iSCSI サービス" が表すプログラムがどれかを認識できる)、特定の機能を記述した定義済みの規則を提供しています。このため、管理者が対応する必要があるのは、規則の対象にする必要があるコンピュータを特定することだけです。これが難しく時間のかかる作業であることに変わりはありませんが、少なくとも環境に固有の作業の 1 つです。
また、カスタムの規則 (図 3 ではドロップダウンのリストで隠れています) もあり、これはファイアウォールの認証で必要だと思われる規則を非常に柔軟に設定できます。たとえば、IPsec 暗号化トラフィックのみを許可する規則が必要な場合、図 2 のウィザードの [アクション] ページでセキュリティで保護された接続のみを許可するオプションを選択します。
このオプションを選択すると、暗号化を有効にするかどうかも指定できます。このチェック ボックスをオフのままにすると、トラフィックは ESP-NULL (NULL キー付きカプセル化セキュリティ ペイロード) を使用します。これは、認証に IPsec を使用する場合の推奨方法です。この場合、トラフィックはネットワーク上で暗号化されずに転送されるため、ほとんどのネットワーク管理ツールの動作が妨げられることがありません。また、暗号化が必要な場合は、このチェック ボックスをオンにするだけでよいのです。
多くの場合、悪意のあるホストからトラフィックを受信することに比べたら、ネットワーク トラフィックの暗号化は些細なことです。ネットワーク トラフィックを暗号化すると、ネットワーク自体にアクセスできる攻撃者がパケット内の情報を盗み出すことを阻止できます。認証を要求すると、パケットの送信自体を防ぎ、攻撃を受けることを回避できます。ネットワーク レベルの暗号化が重要な状況が多数あるのも事実ですが、認証しか必要としない状況も多くあります。

ドメインの分離の規則を作成する
ほとんどの環境では、ワークステーションにトラフィックを送信できるコンピュータの数を制限する必要があります。少なくとも、すべてのワークステーションにドメインの分離の規則を構成する必要があります。これは Windows XP では複雑な作業でしたが、Windows Vista では簡単に行うことができます。
まず、任意の管理ツールを起動し、[接続セキュリティの規則] ノードを選択します。このノードを右クリックし、[新しい規則] をクリックします。図 1 のダイアログ ボックスが表示されたら、規則の種類として [分離] を選択し、[次へ] をクリックします。次に、規則を強制するかどうかを選択します。ほとんどのワークステーションでは、受信トラフィックに認証を要求することをお勧めします。このようにすると、ドメインに参加していないコンピュータからワークステーションにトラフィックが送信されることを防げます。ただし、インフラストラクチャ サービスを使用するには、システムは一部の送信トラフィックがクリア テキストで渡されることを許可する必要があります。したがって、受信接続では認証を必須とし、送信接続では認証を要求することが最適な構成です。
次は、認証方法を選択します。既定で選択されているのは、(あまり役に立たない名前ですが) [既定] というオプションです。IPsec のプロパティでは、コンピュータごとに既定の認証方法を構成できます (プロパティには、[セキュリティが強化された Windows ファイアウォール] ノードを右クリックし、[プロパティ] をクリックしてアクセスできます)。既定の認証方法は、最も簡潔で安全性が高い Kerberos が常に選択されます。ただし、規則を作成するときには、確認のため実際に認証方法を選択することをお勧めします。通常、認証するのはコンピュータのみで、ユーザーの認証は必要としません。両方の認証を必要とすると、匿名で転送される SNMP トラフィックなど、特定の管理トラフィックを受信できなくなる可能性があります。
認証方法を選択したら、後はこの規則を提供するプロファイルを選択するだけです。この規則はドメインに参加していて、Kerberos チケットを提供できるコンピュータに適用されるため、プライベート プロファイルやパブリック プロファイルにこの規則を公開してセキュリティ ホールを作るのは意味がありません。規則を保存したら、作業完了です。
基本的な分離規則は、複雑ではなくなりました。ただし、分離に IPsec を活用するには、ワークステーションにもサーバーの分離を実装する必要があります。これにより、ワークステーションと他のクライアントとの通信を制限し、ワークステーションが、適切な管理ステーションにのみ応答するようにできます。クライアント システムが他のクライアントとの通信を拒否することで、さまざまなマルウェアの発生による影響をどれほど抑えられたかを考えると、これがどれだけ優れた機能であるかをおわかりいただけるでしょう。

ファイアウォールをスクリプトで操作する
新しいファイアウォールには、展開と評価のスクリプト化を可能にする多数の API が用意されています。理想的には、展開にはグループ ポリシーを使用するのが適切ですが、グループ ポリシーは常に利用できるとは限らないので、適切な API セットを使用してファイアウォールを構成することが重要です。この新しいファイアウォールの API は、INetFWPolicy2 API セットとしてグループ化されています。ここでは、理解を助けるため、いくつかの使用例を紹介しますが、詳しい使用方法については、ソフトウェア開発キットと MSDN® ライブラリを参照してください。
よくある例の 1 つとして、規則のグループが有効かどうかを特定する必要がある場合があります。たとえば、アプリケーションや管理者が、あるシステムではファイルとプリンタ共有が許可されているかどうかを特定する必要があるとします。これは、INetFWPolicy2::IsRuleGroupCurrentlyEnabled を利用して確認できます。図 4 は、この処理を行う VBScript サンプルです。
Figure 4 INetFWPolicy2::IsRuleGroupCurrentlyEnabled の使用
' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
    fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if
ファイルとプリンタの共有が無効になっていて、これを有効にする必要がある場合は、まず、この処理を実行できることを確認し、グループ ポリシーによって上書きされないようにする必要があります。これには、INetFWPolicy2::LocalPolicyModifyState API を使用できます。実際に使用するコードを追加できるコード スケルトンを以下に示します。
Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
  Case NET_FW_MODIFY_STATE_OK
  Case NET_FW_MODIFY_STATE_GP_OVERRIDE
  Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

コマンド ラインとインターフェイスの種類
管理用の適切なコマンド ラインがなければ、ファイアウォールは完璧とは言えません。netsh コマンドには advfirewall という名前のサブコンテキストがあります。advfirewall コンテキストを使用すると、GUI から実行できる操作をすべてコマンド ラインから実行できます。たとえば、送信ブロックをポート 445 に実装する場合、次のコマンドを昇格したコマンド プロンプトから実行します。
netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any
ブロックを完全なものにするには、TCP を UDP に置き換えて同じコマンドを実行する必要があります。この 2 つ目のコマンドを実行すると、規則の実装が完了します。
ファイアウォールの便利な機能の 1 つは、ネットワーク インターフェイスの種類に基づいて構成できることです。VPN 接続に影響する規則があることを思い出してください。Windows でインターフェイスが VPN インターフェイスとして認識されれば、この種類の規則を使用して、このインターフェイス経由のトラフィックを除外できます。
netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS
規則を作成すると、この処理を GUI から行うこともできます。作成した規則を右クリックし、[プロパティ] をクリックして、[詳細設定] タブをクリックします。インターフェイスの種類を選択するセクションで、適切なインターフェイスの種類を選択します。

送信フィルタ
Windows XP SP2 のファイアウォールに送信フィルタがないことが、組み込みのファイアウォールでは十分なセキュリティが確保できない最大の証拠として挙げられていました。送信フィルタがない Windows XP SP2 のファイアウォールがいかに安全でないかを記した記事の数は数千にも上るでしょう (しかし、Windows XP 対応ファイアウォールで送信フィルタを安全に提供できるものが、まったくないという事実は考慮されていませんでした)。
送信フィルタを単なる処理速度を遅らせるものから有用なセキュリティ機能に変えるための基本的な機能 (または、前述のようなポリシー強制ツール) は、Windows XP には用意されていません。しかし、Windows Vista では、この機能が導入され、新しいファイアウォールがこの機能を利用しているのはきわめて当然なことです。既定では、ほとんどの受信トラフィックはブロックされ、ほとんどの送信トラフィックは許可されます。
既定では、新しい Windows Vista のファイアウォールの送信フィルタは、サービスから発信された不要なトラフィックのみをブロックします。これは、実は送信フィルタを提供するホストの侵害を防ぐために実施できる唯一の対策ですが、Windows XP では、これを行っても意味がありませんでした。
Windows Vista のサービスは、非常に制限されたトークンで実行できます。基本的に、各サービスには、それぞれに一意な独自のセキュリティ識別子 (SID) があります。このサービス SID を使用して、ネットワーク ポートなどのリソースへのアクセスを制限できます。これは、前述のユーザーへのトラフィックの制限に関する箇所で取り上げた機能と同じものです。つまり、2 つのサービスが NetworkService として実行されていても、これらのサービスでは互いのプロセスを管理することはできず、一方の送信トラフィックしか許可しないようにファイアウォールを構成できます。ポートはサービス SID によって制限されているので、ブロックされている方のサービスが侵害されたとしても、許可されている方のサービスの制御を奪って、許可されているポートを使用して送信を行うことはできません。
この機能も、Windows Vista で追加された非常に便利なセキュリティ機能の 1 つです。新しいファイウォールでは、この機能を使用して、送信ファイアウォール フィルタによる本当のセキュリティの価値を実現しています。
実際、新しいファイアウォールでは、サービス SID に基づくファイアウォール フィルタが既定で有効になっています。これを構成するための GUI はなく、規則は、HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices レジストリ キーであらかじめ定義されています。ただし、このキーを手動で変更することは、サポートされていないため、慎重に行ってください。

送信フィルタが提供できるセキュリティの価値
セキュリティ コミュニティでは、送信フィルタで実際に提供されるセキュリティ価値が大きく誤解されています。これまで、送信フィルタによりセキュリティを確保する 2 つのシナリオを紹介しましたが、どちらも Windows Vista より前のバージョンでは提供されていなかった Windows Vista の新機能に依存しています。それにもかかわらず、一般に、送信フィルタは概ね良いもので、ファイアウォール製品の購入を決めるうえでの主要な検討事項の 1 つにするべきだと考えられています。
皮肉なことに、多くの組織では、送信フィルタ機能が購入の決め手になっているにもかかわらず、ファイアウォールの実装後に送信フィルタは使用されていません。このような考え方は適切ではなく、資金と情報セキュリティ グループの労力の無駄につながります。この考え方は、現実の脅威を実際に分析するのではなく、セキュリティに関する何かを行うことで安心したいという欲求によるものだと思われます。事実に基づいて決められるべきものが、このような "セキュリティ ショー" に対する欲求に基づいて決められているケースがあまりに多すぎます。
送信フィルタの支持者が見逃している非常に純然たる事実があります。多くのホスト ベースのファイアウォールのベンダは、ワームまたは悪意のある対話ユーザーによってシステムが侵害された場合、送信フィルタによって、ワームが他のシステムに感染したり、攻撃者が送信したりすることを回避できると主張しています。しかし、これは真実ではありません。
他のすべての条件が同じであって、送信フィルタを使用すれば、従来のマルウェアの一部は防止できたでしょう。しかし、Windows XP で送信フィルタが提供されていたとしたら、これまで出現したワームは送信フィルタを無効にするか迂回するように作成されていたと思います。
Windows XP (とそれ以前の Windows) では、サービスとして実行されるワームではこれが可能です (一般的に話題になったワームはすべてサービスとして実行されます)。従来のワームで送信フィルタが無効または迂回されなかったのは、単に送信フィルタを使用している環境がなく、これを無効にする必要がなかったからです。対話型攻撃では、攻撃者は自由に送信フィルタを迂回できます。攻撃者が任意のコードを実行できれば、これは簡単なことです。ただし、必要に応じて、攻撃者はユーザーを誘導して送信フィルタを迂回することもできます。
ホスト ベースのファイアウォールの送信フィルタを迂回する方法は複数あり、その方法は攻撃のシナリオによって異なります。最も簡単な方法は、過剰な特権を持つユーザーが攻撃者の代わりに送信フィルタを迂回するように "頼む" ことです。多くの環境では、管理者特権を必要としないユーザーに管理者特権を与えています。このようなユーザーは、自由にセキュリティ ポリシーを迂回する権限を持っています。攻撃者が行う必要のある作業は、不可解な緊急度の低いセキュリティ機能とユーザーにとってより価値のあるもの (つまり、おとり) のいずれかを選択するダイアログ ボックスを提示するだけです。
このようなダイアログ ボックスがあまりに多く表示されるため、多くの場合、ユーザーは実際に何が起きているかを理解することなく、すぐにクリックしてしまいます。これが、送信フィルタの第一の問題です。セキュリティか十分に魅力的な報酬のどちらかを選ぶように求められた場合、必ず後者が選ばれます。これは、セキュリティに関する判断を求めるダイアログ ボックスの大半は、そのような判断を下すのに必要な情報を提供していないためです。
セキュリティに関する判断を求めるダイアログ ボックスで、十分な判断材料となる情報を提供することは、ファイアウォールなどのセキュリティ製品側で、ポート、プロトコル、要求側のアプリケーションについて把握するだけでなく、要求の本当の狙いとそれがユーザーにとってどのような意味を持つかを理解することが必要になるため、実際には困難です。また、このような情報を、プログラムを使用して取得するのは非常に難しいことです。たとえば、Microsoft Word が送信接続を試行しているという事実は、その接続を利用して Word が実行しようとしている具体的な処理が何であるかということに比べたら重要ではありません。
意味のないダイアログ ボックスの数は増やすのではなく減らす必要がありますが、送信フィルタ ファイアウォールはこの点では役に立ちません。ユーザーに価値のある情報を提供するという点で最新の動向を知るために、ホスト ベースのファイアウォールの大手ベンダの販売資料に目を通しました。豪華なパンフレットでは、ファイアウォールの送信フィルタ機能とアドバイス機能が大々的に宣伝されています。アドバイス機能は、ユーザーの操作を検出して、適切なアドバイスを提供する機能です。理論的には、そのようになります。パンフレットには、「現時点では、このプログラムでは、アドバイス機能を利用できません。以下を選択するか、[詳細情報] をクリックしてください。」という文が表示されたスクリーンショットが添えられていました。販売資料の中であっても、ベンダは有用なダイアログ ボックスを提供できないようです。
ユーザーはセキュリティに関する正しい判断を下すのに必要な情報を持っていないので、エンド ユーザーが送信フィルタを構成することはできず、管理者がすべての送信フィルタを構成する責任を負うことになり、管理者の負荷が大幅に高くなります。
ファイアウォールによる確認ダイアログ ボックスで [いいえ、また後で確認する] をクリックしても、通常、マルウェアはファイアウォールを迂回できてしまいます。悪意のあるコードを実行するユーザーがいずれかのポートで送信接続を開くことができれば、有害なコードはそのポートを使用できます。したがって、どのプロセスでも、既存のプロセスに便乗できます。以前のオペレーティング システムでは、これが可能でした。Windows Vista と今後リリースされる Windows では、プロセスを適切に制限できるので、送信フィルタを使用して、サービス (既定の制限対象) を既定でブロックできます。
残念ながら、ほとんどの人が、ホスト ベースのファイアウォールの送信フィルタを使用すると、侵害された資産からの他の資産への攻撃を防げると考えています。しかし、それは不可能です。侵害された資産に保護対策を施して、他の資産を侵害しないことを望んでも、うまくいきません。保護対策は、その対策を講じた資産に属するもので、それ以外の資産を保護するのには役立ちません。既に家の中に侵入している不審者に何も盗まないように頼んでも、そもそも家の中に押し入られないための対策を講じた場合と同じ効果が得られないのと同じことです。

Jesper M. Johansson は、セキュリティ ソフトウェアの開発に取り組むソフトウェア アーキテクトで、TechNet Magazine の編集にも携わっています。管理情報システムの博士号を持ち、セキュリティ分野で 20 年以上の経験があります。また、エンタープライズ セキュリティの Microsoft MVP でもあります。最新の著書には、『Windows Server 2008 Security Resource Kit』があります。


セキュリティ
デジタル証明書を使用して電子メールをセキュリティで保護する
Matt Clapham and Blake Hutchinson
概要:
  • 検証可能な ID を作成する
  • 証明書の状態を更新する
  • 証明書を取得および交換する
  • S/MIME システムのトラブルシューティングを行う

数千年もの間、人類は、運送中 (送信中) の情報の秘匿、送信者の確認、およびメッセージの認証にさまざまな方法を使用してきました。文明の進化により、この 3 つの全作業を行う 1 つの方法が考案され、普及しました。それが Secure Multi-Purpose Internet Mail Extensions (S/MIME) です。
S/MIME は、暗号化とデジタル署名を使用して電子メールを安全に送信するための仕組みです。
現在の暗号化 (秘匿) 技術は 2 種類に分類できます。対称 (共通) キー アルゴリズムと非対称 (公開/秘密) キー アルゴリズムです。前者に該当するテクノロジは DES (Data Encryption Standard) や AES (Advanced Encryption Standard) で、RAS や ECC (Elliptical Curve Cryptography) は後者に該当するテクノロジです。送信者を確認する最新のツールでは、一意な署名を作成するハッシュという一方向の数学関数が採用されています。一般的に使用されるハッシュ関数は、MD5 (Message Digest Algorithm 5) と SHA (Secure Hash Algorithm) の 2 つです。コンピュータでは、これらの関数を使用して、各ソース テキストに対応する一意なハッシュを生成できます (ソース テキストが同じ場合は、生成されるハッシュも同じになります)。公開キー基盤 (PKI) システムは、このような単純なツールを組み合わせて実現されています。

検証可能な ID を作成する
証明機関の関連情報
  • 暗号化ファイル サービスに証明機関を使用する
  • 証明機関サーバーをリネームまたは削除できない
  • ドメイン内のコンピュータから信頼された証明機関を削除する方法
  • Windows エンタープライズ証明機関の使用を停止する方法と、Windows Server 2003 および Windows 2000 Server から関連するすべてのオブジェクトを削除する方法
  • ドメイン コントローラで証明機関を新しいサーバーに移行する方法

PKI システムでは、ID はデジタル証明書を使用して管理されています。デジタル証明書は、大半の人が海外旅行をする際に携帯する政府が発行する身分証明書 (パスポート) とは異なります。デジタル証明書の世界でパスポートに相当する標準は X.509 形式です。この形式は、S/MIME、インターネット プロトコル セキュリティ (IPsec)、SSH (Secure Shell)、ワイヤレス ネットワーク セキュリティ、仮想プライベート ネットワーク (VPN)、セキュリティで保護されたサーバー通信 (たとえば、SSL を使用した Web サイト) などの署名テクノロジと暗号化テクノロジの両方で広く使用されています。
証明書は、非対称暗号化とハッシュをベースに作成されています。証明書を作成するには、要求側 (より信頼性の高い機関が署名したキーを必要としているエンティティ) が秘密キーを作成します。このキーは、キーの信頼性が問題になることがないように隔離します。この秘密キーと同時に対応する公開キーが生成されます。名前から推測できるように、このキー ペアの公開される側のキーは、このキーの信頼性が保証される方法で自由に配布することが可能です。
このキー ペアにより、2 つの基本的な操作が可能になります。1 つは、公開キーを使用した暗号化です (このような暗号化物の暗号化を解除するには対応する秘密キーが必要です)。もう 1 つは、秘密キーを使用した暗号化物の暗号化解除に公開キーを使用することです。これは、秘密キーを使用してでしか作成することができない署名を検証するうえで重要です。
証明機関への要求には、キーを使用するユーザーまたはコンピュータの ID、アルゴリズムの種類と強度、キー ペアの公開される側のキーなどの詳細情報が含まれます。証明機関 (CA) では、要求に含まれる情報を受信して検証し、ハッシュ アルゴリズムを使用して、その情報に対応する一意な ID を作成します。
CA では、対応する秘密キーを使用して、その情報のハッシュを暗号化し、標準的な形式 (X.509 など) にして、要求に対応する証明書を作成します。X.509 証明書には、証明書の ID (サブジェクト)、有効期間、公開キー、および許可されている証明書の目的など、権利の一覧が含まれています。作成された証明書は、要求側に返されます。証明書は、「発行元の CA は、ここに記載されたあらゆる用途に関して、この公開キーとそれに対応する秘密キーを保証します」ということを宣言している効力のある証です。
ルート CA の証明書は自己署名証明書です (ルート CA は、信頼チェーンにおける最上位レベルの CA です)。オペレーティング システムやアプリケーションには、実績のある大手の証明機関がルート CA として、あらかじめインストールされていますが、パッケージや企業の構成によって更新または変更されることがあります。ルート CA とリーフ ノード間には、1 つ以上の中間 CA が存在することがあります (通常、リーフ ノードという表現は、個人ユーザーやシステムを指して使用します)。
信頼チェーンは、すべてのノードとノードに組み込まれていて、ノードと同レベルの CA の署名が入っている上記の全証明書で構成されています。証明書を検証する必要がある第三者は、当該 CA またはユーザーの対応する公開キーを使用して証明書から暗号化解除したハッシュとローカルで計算されたハッシュを照合できます。検証に必要な作業は、それだけです。リーフからルートまでの信頼性が保証されている信頼チェーンでは、当然、ルート CA が信頼されます。

証明書の状態を更新する
優良な CA は、信頼されなくなった証明書の一覧を配布する手段を備えています。この証明書失効リスト (CRL) には、CA が明示的に失効させた証明書が記載されています。便利なことに、通常、CRL は CA 証明書のプロパティからアクセスできます。
CA では、2 つの基準で定期的に CRL を発行します。スケジュール (2 週間ごとなど) に基づいて発行する場合と、イベント (発行した証明書が信頼できなくなったことを示すイベントなど) が発生した場合に CRL を発行します。CA では、CRL の発行時に CRL に署名をします。証明書を受け取ったシステムが信頼チェーンの有効性を評価する際には、発行元 CA の CRL の取得を試行します (これには、証明書自体に含まれている詳細情報を使用するか、あらかじめ定義された信頼できる配布メカニズムを使用します)。CRL が利用できない場合、クライアント システムでは、正常にキャッシュされた最新のコピーを参照することがあります (ただし、指定された CRL 更新期間が過ぎていない場合に限ります)。この処理も行えない場合、通常、クライアント システムでは、証明書は有効であるように見えるが、失効状態を特定できないということを示すエラー メッセージが表示されます。
信頼チェーンまたは信頼チェーンの各ノードの CRL を検証できない場合、多くのアプリケーションでは、証明書の読み込みにかかる時間がかなり長くなります。証明書で保護している対象によっては、その証明書を信頼するかどうかをユーザーが判断しなければならない場合があります。定期的に更新され、広い範囲で使用できる CRL 配布ポイントは、すべての CA で必要です。特に、パブリックなルート CA では必要です。
ルート CA は証明書の信頼チェーンの基盤となり、信頼チェーンは全証明書の階層の基盤となります。多くのクライアント システムやアプリケーションでは、信頼チェーンが信頼されているルート CA まで続いている場合に限り、リーフ ノードの証明書が有効であると見なします。ルート CA は、その企業が所有して運用しているエンタープライズ CA である場合もあれば、パブリックなルート CA (VeriSign など) の場合もあります。
パブリックなルート CA の場合、完全性を保証するための専門的な運用技術が必要になります。ルート CA の信頼性は重要なので、エンタープライズ CA の運用においても同様のレベルの精度を実現するために最善の努力をする必要があります。最も強固な保護を実現するには、ルート CA は、オフラインにして、証明書の発行時と CRL の更新時にのみ使用することをお勧めします。CA の運用に関するベスト プラクティスについては、「証明書機関の関連情報」を参照してください。
キーの回復は、検討する必要がある重要事項です。企業で投資を有効活用し、データがユーザーによって回復できない状態に陥ることがないようにするには、ユーザーが発行したキーのバックアップ コピーを作成することをお勧めします。また、このようなバックアップ コピーは、安全なリポジトリに格納する必要があります。このような対策を講じると、たとえば、スマート カードをタクシーに置き忘れて、ユーザーがキーを紛失しても、そのキーで保護されているデータにアクセスすることができます。
優良な暗号化システムでは、ライフサイクル管理の概念が重要になります。コンピュータの処理速度が高くなるほど、アルゴリズムは脆弱になります。優良な暗号化システムは、時間の経過とともに、システムを更新して、新しいアルゴリズムとキーのサイズに移行する必要があります。また、CA は、暗号化アルゴリズムの脆弱性が明らかになったり、新しい関数が導入されたり、既存の関数が廃止されたりした場合には、適宜更新する必要があります。

S/MIME を実装する
S/MIME を使用して、署名または暗号化した電子メールをブートストラップ、構成、および送受信するには、いくつかの段階があります。ここでは S/MIME の一般的なシナリオを使用して、実装の詳細を説明し、実装に関する問題とその解決策を紹介します。2 つの異なる Active Direcroty® フォレストと 2 つの異なる証明機関の信頼チェーンに属している 2 人のユーザーが、Microsoft® Office Outlook® 2007 を使用して署名または暗号化した、あるいはその両方が行われた電子メールをやり取りしています (この 2 人のユーザーは同じ会社内で働いているかどうかに関係なく、運用上は別のエンティティからメールを送受信しているということになります)。
ここで説明する操作に必要なインフラストラクチャは既に整備されていることを前提としています。このシナリオでは、Active Directory に統合されたエンタープライズ CA サーバーを使用します。

証明書を取得する
まず、適切な証明書を取得する必要があります。これには、証明書マネージャ MMC (certmgr.msc) を起動し、[個人] フォルダを右クリックして、[すべてのタスク] をポイントし、[新しい証明書の要求] をクリックします。
この操作により、証明書の登録ウィザード (図 1 参照) が表示されます。既定では、企業向けのいくつかのオプションが表示されますが、ユーザー証明書が重要です。ユーザー証明書は、後で署名と暗号化の処理を有効にする際に使用します。証明書は、次の用途に使用できる必要があります。
図 1 証明書の要求
図 1 証明書の要求 (画像を拡大するには、ここをクリックします)
  • デジタル署名 (作成者の認証で封印されたメッセージを作成する)
  • キーの暗号化 (暗号化ファイル システムなどのテクノロジで、キーを相互に保護する)
  • 電子メールの保護 (対応する秘密キーを所有している然るべき受信者しか読むことができないようにメッセージを暗号化する)
S/MIME を使用して署名した電子メールを送信する場合、キーの暗号化は必要ありませんが、暗号化したメールを送受信する場合は、キーの暗号化が必要になります (ただし、デジタル署名は必要ありません)。既定では、Windows® 証明書サービスによって、この 3 つの用途が有効になっています。新しい証明書を要求することが許可されていない場合、ウィザードには何も表示されません。使用できるエンタープライズ CA がない場合、ドメインまたは CA にアクセスできないことを示すエラー メッセージが表示されます。このシナリオでは、署名と暗号化の両方を許可する単一の証明書を使用することをお勧めします。

証明書を交換する
2 人のユーザーが暗号化した電子メールを送信できるようにする最も簡単な方法は、署名したメッセージを互いに送ることです。必要な作業は、メッセージの作成後に [署名] ボタンをクリックするだけです (このボタンを一度も使用したことがない場合、Outlook の既定の設定では、このボタンが非表示になっていることがあります。新しいメッセージのウィンドウで [オプション] をクリックして、[セキュリティ設定] ボタンをクリックして、[セキュリティのプロパティ] ダイアログ ボックスの [このメッセージにデジタル署名を追加する] チェック ボックスをオンにすると表示されるようになります)。[署名] ボタンをクリックすると、メッセージにデジタル署名が追加され、メッセージの作成者の信頼性が証明されます。このボタンには、小さな黄色い封筒に赤いリボンが付いていて、ポイントすると "署名" というテキストが表示されます。
[送信] ボタンをクリックすると、スマート カードを挿入したり、PIN を入力するなど、キーを所有していることを証明する追加の証拠となるものを提示するように求められることがあります。このボタンをクリックしたときの動作は、組織で採用されているキーの保護方法によって異なります。
S/MIME を使用して署名されたメッセージを受信したユーザーは、"差出人:" の後に表示されている送信者の名前を確認し、名前を右クリックして、[Outlook の連絡先に追加] をクリックする必要があります。この操作により、新しい連絡先エントリが追加されるか、既存の連絡先エントリが更新されます。この操作により、証明書が、その特定の連絡先エントリに関連付けられます。2 人のユーザーが同じフォレストまたは社内にいるという一般的な Active Directory の環境では、ユーザーの Active Directory オブジェクトの属性により、パブリック用のユーザー証明書が自動的に配布されます。
証明書を交換する別の方法としては、各ユーザーが、各自の S/MIME 証明書を添付ファイルとして送信することができます。これを行うには、双方のユーザーが、各自の証明書を CER ファイルとしてエクスポートする必要があります。ユーザーは証明書を表示して、この後説明するエクスポート手順を実行する必要があります。また、この際、図 2 に示すように、秘密キーをエクスポートしないように注意する必要があります。
図 2 証明書をやり取りする際には秘密キーをエクスポートしないように注意する必要がある
図 2 証明書をやり取りする際には秘密キーをエクスポートしないように注意する必要がある (画像を拡大するには、ここをクリックします)
証明書を受信したら、Outlook で連絡先エントリを手動で作成し、送信者のエントリに証明書を追加します。証明書を交換したら、その後は、互い暗号化した電子メールを送受信することができます。

トラブルシューティング
受信者が暗号化されたメッセージを開けないことがあります。この問題の原因として可能性が高いのは、ルート CA が信頼されていない、中間証明機関が確認できない、または CRL が利用できないことです。
通常、ルート CA が信頼されていない場合、Outlook では、"署名に問題があります。詳細を表示するには、[署名] ボタンをクリックしてください。" という署名に関するエラー メッセージが表示されます。この問題を解決するには、Outlook 内から証明書を開き、ポップアップ ダイアログ ボックスの [証明機関の表示] ボタンをクリックします。証明書プロパティ ダイアログ ボックスの [全般] タブに表示されているメッセージを確認します。CA ルートから発行された証明書が信頼されておらず、インストールする必要があることが示されている場合は、[詳細] タブをクリックします。[ファイルにコピー] ボタンをクリックし、ウィザードの指示に従います。ウィザードでは既定の設定を使用し、ファイル名とフォルダを指定するページでは、これらの情報を指定します。
コンピュータの管理者として、新しい Microsoft 管理コンソール (MMC) を起動します。[ファイル] メニューの [スナップインの追加と削除] をクリックして (または、Ctrl キーを押しながら M キーを押して)、[証明書] を選択し、管理する証明書を指定するように求められたら [コンピュータ アカウント] をクリックします。左側のツリーで [証明書] ノードを展開し、[信頼されたルート証明機関] を展開します。このノードを右クリックし、[すべてのタスク] をポイントして、[インポート] をクリックします。前述のエクスポートした証明書ファイルを信頼されたルート証明機関の証明書としてインポートし、[完了] をクリックします。その後、この問題が発生したユーザーに Outlook を再起動するように指示します。
この手順は、信頼できることが確認されているルート CA を追加する場合にのみ使用してください。すべてのルート CA が同じように作成されているとは限りません。この手順を使用して全システムの証明書ストアにルート CA を追加する前に、そのルート CA の所有者と運用者について十分検討してください。組織で、グループ ポリシーを使用して信頼されたルート証明機関の一覧を管理している場合は、構成がクライアント システムに展開されます。その場合、この手順を使用しても問題が解決しない可能性があります。この手順を使用しても問題が解決しない場合は、電子メールではシームレスでセキュリティが保護された操作性を実現できないので、データのやり取りには、セキュリティで保護された Web サイトやサーバーを使用する必要があります。
中間証明機関が確認できないことが原因であるという 2 つ目の問題が発生する主な状況は 2 つあります。1 つは、証明書の検証を試行しているクライアントが証明書で定義されている機関情報アクセス (AIA) の場所にアクセスできない場合です。もう 1 つは、中間証明機関が発行しているものと一致しない証明書をクライアントが所有している場合です (クライアントでは、CA が所有している証明書よりも 1 ～ 2 バージョン古いものを所有していることがあります)。このような状況は、Outlook のユーザー インターフェイスでも同じように発生します。この問題は、信頼チェーンに含まれる中間レベルの CA が発行した他の従属証明書が失効する前に、親証明書が失効するという非常に特殊な状況でのみ発生することが確認されています。
基本的に、この問題は、証明書チェーンに断絶がある場合に発生します。親証明書の詳細情報が不足していたり、親証明書が適切にリーフ ノードに組み込まれていないと、状況がさらに複雑になります。
この問題を解決するには、送信者が新しいメッセージを作成し、[オプション]、[セキュリティ設定]、[設定の変更] を順にクリックする必要があります。その後、署名証明書の [選択] ボタンをクリックし、ポップアップ ダイアログ ボックスの [証明書の表示] をクリックします。[証明のパス] タブをクリックし、リーフ ノードの発行者 (証明書チェーンの 1 つ上位レベルのノード) を選択し、[証明書の表示] ボタンをクリックします。[詳細] タブをクリックし、[ファイルへコピー] ボタンをクリックし、エクスポート ウィザードの指示に従います。エクスポート ファイルの形式を選択するページでは、[Cryptographic Message Syntax Standard - PKCS #7 証明書 (*.P7B)] をクリックし、[証明のパスにあるすべての証明書を含める] チェック ボックスがオンになっていることを確認します (図 3 参照)。最後に、エクスポートした証明書チェーンのファイルを然るべきユーザーに送信します。
図 3 証明書チェーンにある断絶の修正
図 3 証明書チェーンにある断絶の修正 (画像を拡大するには、ここをクリックします)
エクスポートした証明書チェーンを受け取ったら、受信者は、ファイルを開いて、ルート CA のインポートと同じ手順で証明書チェーンをインポートする必要があります。唯一異なるのは、保存先のフォルダとして [中間証明機関] を選択する必要があることです。メッセージが開けるようになり、証明書が Outlook で有効なものとして表示されれば、問題が解決したということになります。
CRL が利用できないという 3 つ目の問題は、比較的簡単に解決できます。Outlook の状態は、1 つ目と 2 つ目の問題と非常によく似ていますが、ルート署名 CA または中間署名 CA が信頼されている場合にもエラーが表示されることはあります。リーフ ノードの上位に位置する証明書チェーンの各レベルで、証明書のプロパティ ダイアログ ボックスを開いて、[詳細] タブの "CRL 配布ポイント" フィールドの設定を確認します。
このフィールドに表示されている CRL 配布ポイント (特に、インターネットにアクセスできる配布ポイント) ごとに、その CRL ファイルの URL にアクセスできるかどうかを確認します。確認を行う際には、チェーンの下位から上位に向かって作業を進めます。CRL が利用できないレベルがある場合、そのレベルが問題の原因である可能性があります。この問題を解決するには、ローカル ネットワーク ポリシーによってアクセスがブロックされていないことを確認する必要があります。他の解決策としては、CA を所有している企業に連絡するか、CA の CRL 配布ポイントが利用できるようになるまで待機します。

証明書を配布する
配布は簡単に行えます。基本的に、署名したメッセージはメール サーバーに転送され、メール サーバーでは信頼できる SMTP を使用してメッセージが送信されます。署名または暗号化したメールの送信に関して発生する問題は、メール システムによってメッセージが拒否されたり、メール システムを経由するときにメッセージが破損することがあるという問題です。この問題を解決するには、そのようなメール システムの IT 管理者に働きかけて、このような種類のメッセージを許可するようにしてもらう必要があります。もちろん、特定のメッセージの種類がブロックされるという状況を受け入れなければならないこともあります。メッセージを受信する側には、特定の運用環境で暗号化されたメッセージを許可しない然るべき理由がある場合があります。

返信メッセージを暗号化する
返信メッセージを暗号化するのに必要な作業は、メッセージを作成して、メッセージ ウィンドウで [暗号化] ボタンをクリックするだけです (ただし、上記のブートストラップの手順が完了していることが前提となります)。このボタンには、小さな黄色い封筒に青い鍵が付いていて、ポイントすると "暗号化" というテキストが表示されます。[暗号化] ボタンが表示されていない場合は、署名したメッセージの送信についての箇所で提示した手順に従います。唯一異なるのは、最後の手順で [メッセージの内容と添付ファイルを暗号化する] チェック ボックスをオンにすることです。
暗号化したメッセージを送信する際には S/MIME による署名は必要ありませんが、両者は相性がよい機能です。暗号化機能では、送信者としての申し立ては一切行わないので、署名を使用すると受信者が送信者を確認できるようになります。暗号化処理では、すべての受信者の公開キーを使用してメッセージを暗号化します。一部の受信者の証明書がシステムに見つからない場合は、メッセージを暗号化しないで送信することを推奨するポップアップ ダイアログ ボックスに当該受信者の名前が表示されます (図 4 参照)。
図 4 証明書に関して問題が発生した場合はメッセージを暗号化しない状態で送信できる
図 4 証明書に関して問題が発生した場合はメッセージを暗号化しない状態で送信できる (画像を拡大するには、ここをクリックします)
既定では、署名と暗号化は、他の同じように構成されたクライアント システムとは問題なく動作します。ただし、下位レベルのシステムでハッシュや暗号化アルゴリズムがサポートされていない場合には、複数のバージョンにまたがる暗号化または署名を伴うメッセージのやり取りで問題が発生することがあります。このような問題は、Windows XP SP2 コンピュータを使用しているユーザーに、(SHA-512 をハッシュ アルゴリズムとして使用して) 署名した電子メールを送信したときに発生しました。受信側のシステムではハッシュがサポートされていなかったので、ユーザーは署名を確認することも、メッセージを読むこともできませんでした。ただし、Outlook の既定の設定を使用していれば、ユーザーが多くの問題に直面することはほとんどありません。
パブリック用の証明書に対応する秘密キーを保持している場合、メッセージの受信者はメッセージを開くことができます。また、秘密キーの展開方法によっては、秘密キーを所有していることを証明する追加の証拠となるものを提示するように求められることがあります。同様のブートストラップの手順を行ったユーザーは、このような署名および暗号化されたメッセージを他の送信者とやり取りすることができます。ユーザーがコンピュータの紛失などにより秘密キーを変更した場合には、暗号化したメールをやり取りする必要があるユーザーに、証明書を再度要求し、署名したメッセージや証明書ファイルを再配布する必要があります。

まとめ
通常、2 つの異なるディレクトリや組織に所属する 2 人のユーザーが S/MIME を使用して署名および暗号化したメッセージをやり取りすることは、この記事で説明した以上に複雑になることはありません。署名は適切に使用すると、メッセージに信頼性を追加できるので、非常に便利なものです。機密情報に関しては、メッセージを暗号化することで、送信中のデータの機密性が強化されます。署名と暗号化を組み合わせて使用すると、データの提供元の信頼性とデータの機密性の両方を確保できます。また、この記事で説明した手順を使用すれば、大多数のユーザーにとって、これらの機能を使用するのは、それほど大変なことではありません。

Matt Clapham は CISSP 資格保持者で、Microsoft IT でセキュリティ エンジニアとして働いています。日中は LOB アプリケーションのセキュリティ レビューを行い、夜はテクノロジ、ゲーム、コンピュータ ミュージック、またはセキュリティにもちょっと手を伸ばしています。また、ピュジェット湾周辺の IT セキュリティ コミュニティを対象に講演を行うこともあります。連絡先は、matt.clapham@microsoft.com (英語のみ) です。
Blake Hutchinson は、マイクロソフトの Business Online Services Group (BOSG) でサポート アナリストとして働いています。彼の任務は、社内で BOSG の法人顧客向けに作成した LOB ツールの運用サポートとプロジェクト レビューです。趣味は、写真、スキー、コンピュータ ゲームです。連絡先は blakeh@microsoft.com (英語のみ) です。


編集長から 大論争
Joshua Hoffman

私は大論争が好きです。 といっても、意見の違いと個性の強さが愚かな対立を引き起こす、つまらない口論のことを言っているのではありません。そうした口論は、時間の無駄もいいところです。一方、思慮深い人々が対立する意見を持って集まり、激しく議論を展開して物事を検討する真の大論争は、強い影響力があります。たとえば、啓蒙運動やソクラテスを想像してみてください。
今月は、IT 業界における真の大論争の 1 つである「隠すことによるセキュリティ」について紹介します。ここでその概念を説明してもかまいませんが、私はひそかに、多くの人はこの「隠すことによるセキュリティ」という表現を見て、既にこのテーマについてご自身の意見を (おそらく声に出して) 述べているのではないかと思っています。また、皆さんの意見は、ほぼ真っ二つに割れていて、"隠すことによるセキュリティは少しも役に立たない" または "セキュリティに関しては、どんな些細なことでも役に立つ" のいずれかに該当しているに違いないでしょう。
そこで今月は、セキュリティの専門家として名高い Jesper Johansson と Roger Grimes を引き合わせて、この議論の 2 つの立場を説明します。また、この記事には、それぞれの立場を支援する、2 人の権威 Aaron Margosis と Steve Riley による特別解説も収録しました。私は、公開しているすべての記事にとても満足していますが、正直なところ、この記事は、久しぶりに特に気に入っている記事の 1 つです。この記事は、大論争でどちらの立場を支持するかにかかわらず、偏見を持たずに読み進めることをお勧めします。どうぞお楽しみください。
もちろん、この毎年恒例のセキュリティ特集では、さらに多くのテーマを取り上げています。今年は、昨年の特集で説明したトピックの一部を再び取り上げています。昨年、最も好評だった記事の 1 つは、編集にも携わっている Michael Murgolo による、一連のスクリプト昇格 Power Toy について説明したものです。これは、VBScript または Windows PowerShell スクリプトを Windows Vista のユーザー アカウント制御機能を使用して、昇格したコンテキストで実行するのに役立ちました。Michael には、この記事に関して非常に多くの肯定的なフィードバックが寄せられました。そこで今年は、昨年紹介したコードを拡張するまったく新しいユーティリティ セットを用意して帰ってきました。この非常に強力なツールを、ぜひお試しください。
Byron Hynes は、昨年の特集で Windows Vista の BitLocker ドライブ暗号化について概説しましたが、今年は、Windows Vista SP1 と Windows Server 2008 のリリースにおける BitLocker の変更点について説明した記事を執筆しました。それ以外に、ソフトウェアの制限のポリシー、Windows Vista のファイアウォールの管理、S/MIME のトラブルシューティング、新コラム「SharePoint の内部」第 2 回、持続可能なコンピューティングを促進するためのビジネス アイデアなどに関する記事もご用意しています。お楽しみに。—Joshua Hoffman

次のマイクロソフト技術支援スタッフに心より感謝します。Troy Funk、Aaron Margosis、Michael Murgolo、Steve Peschka、Steve Riley、Mark Russinovich、Jon Schwartz、Jim Truher


レター 読者の皆さんからの声

Windows バックアップ
Windows Server® 2008 についての記事 (TechNet Magazine、2008 年 3 月号 technet.microsoft.com/magazine/cc268370) を読んでわくわくしたので、発売イベントに行って自宅のホーム ネットワークで使用するためにソフトを購入しました。インストールはすべてうまく行きましたが、バックアップで困ってしまいました。
NT バックアップが廃止されており、OS ではテープ ドライブがサポートされていますが、新しい Windows Server バックアップではテープ ドライブがサポートされていません (Active Directory® と Exchange Server 2007 を含む個人的なデータはテープ ドライブにバックアップしています)。
私の環境では機能を持て余すと思ったのですが、インターネットで得たヒントに従って、Microsoft® Data Protection Manager (DPM) をダウンロードしました。しかし、Windows Server 2008 には DPM をインストールできず、手動でのインストール手順もうまく行きませんでした。このような小規模の環境でバックアップを行うにはどうしたらいいのでしょうか。
—Ravi S

Windows Server 2008 で導入された新しいバックアップ機能はディスク ベースのストレージ用に最適化されているので、テープ バックアップの解決方法が DPM ということで間違いありません。DPM は、数か月以内に正式に Windows Server 2008 でサポートされるようになります。
—Karandeep Anand (シニア プログラム マネージャ リード、Microsoft)

アンケート ワークフロー
2008 年 2 月号の記事「強力なアンケート用インフラストラクチャを構築する」(technet.microsoft.com/magazine/cc194407) の、「WSS 単体で作業する」のセクションには "また、アンケートにワークフローを割り当てることもできます" という記述がありました。
Windows® SharePoint® Services 3.0 (WSS) と Microsoft Office SharePoint Server 2007 (MOSS) ではアンケートの回答に関するワークフローはサポートしていないと理解しています。SharePoint Designer では関連付けを行うことができますが、アンケートの回答にワークフローの関連付けを試行すると、ワークフローは "開始時に失敗" というエラーで失敗します。アンケートの回答に関連付けられたワークフローがサポートされていないことを明記したサポート技術情報の記事 (support.microsoft.com/kb/926370) があります。
イベント レシーバとアンケートをリンクさせてから、他のプロセスを開始することが可能であることはわかっていますが、これは SharePoint で一般的に参照されるワークフローではありません。この記述が間違っているのでしょうか。それともここで私が何か見落としているのでしょうか。
—Matt B

参照された段落では、WSS がアンケートを作成する段階的なプロセスのウィザードをどのように提供するのかについて説明しています。また、さまざまなオプション (分岐ロジック、オープン/クローズド クエスチョンなど) についても説明しています。
このウィザードが実際に提供しているオプションの 1 つが、ワークフローの割り当てです。ですから、ある意味では「アンケートにワークフローを割り当てることもできます」という記述は必ずしも間違っているというわけではありません。割り当てることはできます。ただし、ご指摘のように、オプションがなんらかの理由で含まれていたとしても、アンケートのワークフローではとにかく機能しません。その機能しない理由をご説明しましょう。
アンケートをワークフローと関連付けて、開始しようとすると、"開始時に失敗" エラー メッセージが表示されます。この動作状況のログは次のようになります。
RunWorkflow: System.ArgumentException: Invalid field name.
{<<< GUID>>>} at ...
このログの GUID はワークフロー インスタンスを示します。これは、リストの種類が "アンケート" のワークフローでワークフロー属性がサポートされていないことを除けば、適切なワークフローがトリガされるようにするのに便利な方法であるように見えます。しかし、コーディングされていないという問題があります。そのため、ワークフローで MakeActivation メソッドを使用してアクティブ化を試行すると、次のような処理が行われます。
internal static void MakeActivation(SPWorkflow workflow, SPWorkflowEvent e)
{e.EventData = new object[ ] { workflow.InstanceId, new SPWorkflowActivation
Properties(workflow, e.RunAsUserId, associationData, initiationData) };
...
}
次のような SPWorkflowActivationProperties を呼び出します。
internal SPWorkflowActivationProperties(SPWorkflow workflow,
int runAsUserId, string associationData, string initiationData)
{
...
this.m_itemGuid = new Guid((string)
this.Item[SPBuiltInFieldId.GUID]);
...
}
ここで、GUID 文字列がアンケートの属性であることが期待されているときに (本来ならば、そうあるべきですが)、アンケートに当該ワークフロー GUID の属性がなければ、動作しません。
解決策がありますので、考え方は間違っていません。その解決策は、ワークフローをトリガするカスタム リストを作成して、イベント レシーバを ItemEventReceiver とアンケートにリンクさせることです。このイベント レシーバは、カスタム リストのアイテムを作成し、この作成したアイテムによりワークフローがトリガされます。しかし、ご指摘のとおり、これはご希望の処理と同一ではありません。手短に言うと、実際に動作しないことに、よくお気付きになったと思います。
—Pav Cherny (コラムニスト、TechNet Magazine「SharePoint の内部」担当)


ツールボックス IT プロフェッショナル向けの新製品
Greg Steen

ネットワーク上にアナウンスを流す
NetSupport Notify
www.netsupportnotify.com
仕事場では、ほとんどの場合、PC ベースの作業環境をいつでも利用できます。ほとんどのユーザーは一日中、あなたが管理するネットワークに接続された PC の前に座っています。企業のネットワークは、共有のリソース、アプリケーション、およびインターネットのトランスポート手段を提供するばかりでなく、ユーザーに重要なメッセージを送る組織戦略の一部として利用することもできます。LAN やワイド エリア ネットワーク (WAN) を通じてメッセージを配信できるツールの 1 つに、NetSupport Limited から出されている NetSupport Notify があります。
この軽量なアプリケーション サーバーを利用することにより、迅速で信頼性の高いブロードキャスト メッセージ サポートを得ることができます。たとえば、共有リソース サービスの予期しない停止についてユーザーに警告したり、セキュリティ警告が発せられた原因が事故によるものであったことをユーザーに伝えたり、ビルの非常事態を従業員に知らせたりすることが簡単にできます。
いくつかのシンプルなブロードキャスト メッセージ ツールがありますが、メッセージを送信できる範囲はツールがインストールされた LAN に限られます。ただし、エージェントベースの NetSupport Notify では、通知用ゲートウェイ コンポーネントを使用し、簡単にネットワーク トポロジを経由して、直接接続、ワイヤレス接続、または仮想プライベート ネットワークを介して接続されている Windows® クライアントおよび Mac クライアントの両方にメッセージを送信できます。
通知サービスは Windows サービスとして実行され、同じマシンまたは異なるマシンにインストールされた管理用通知コンソールを経由してサービスに接続できます。サービスから送信される通知は、メッセージ、警告、重大という 3 つの重要度のレベルのうちの 1 つに分類されます。クライアントがメッセージを受信すると、イベント ログのエントリが作成され、メッセージが受信されたことをサーバーに通知します。他のメッセージのオプションとして、ウィンドウにメッセージを表示すると同時に警告音を鳴らしたり、強制的に通知が常に画面に表示されるようにしたり、メッセージに自動タイムアウトを設定して、自動的に閉じるようにしたりできます。
また、特定の通知グループのみを対象として選択することもできます。通知コンソールは複数の通知サーバーに接続できるため、1 つのコンソールをメッセージ ブロードキャストの中心にすることができます。
サーバーとコンソールだけでなく、NetSupport Notify には展開ツールが含まれており、このツールを使用してエージェントをリモートでエンド ユーザーに展開できるため、わざわざユーザーのデスクトップに出向く必要もなくなります。ターゲット マシンは、IP アドレスの範囲、または Windows ネットワーク ドメインとワークグループ検出を使用することによって指定できます。
展開コンソールを使用して、ネットワークを簡単に表示させることもできます。インストールされているエージェントのバージョンだけでなく、DNS 名、MAC アドレス、IP アドレス、プラットフォーム、およびコンソールがリモート マシンにアクセスできるかどうかなどの情報も表示されます。Active Directory® を使用している場合は、グループ ポリシーを通じて構成と展開を管理できます。
無許可のブロードキャスト (「4 時から僕のオフィスでパーティを開くんだけど、来ない?」など) を防止するために、エージェントとコンソールでは Windows Management Instrumentation (WMI) キー文字列に類似したセキュリティ コードが使用されています。さらに、Active Directory ポリシーを通じて警告を送信する機能を制御することもできます。
価格 : 75 ユーザー ライセンスあたり 180 ドル～
NetSupport Notify を使用して、社員にアナウンスを配信する
NetSupport Notify を使用して、社員にアナウンスを配信する (画像を拡大するには、ここをクリックします)

ネットワークを監視する
NetOptics: Teeny Tap
www.netoptics.com
パッシブ ネットワーク タップは、優れた監視アプリケーションと共に使用すれば、不安定なネットワークのトラブルシューティング、不適切に動作するアプリケーションの修正、およびインフラストラクチャに対する潜在的脅威の軽減に不可欠なツールとなります。10/100 ネットワークで私が注目する優れたタップの 1 つは、NetOptics から出されている、非常にコンパクトな Teeny Tap です。
大きさがわずか 7.938 × 3.81 cm のデバイスは、レイヤ 1 以降の全二重トラフィックの監視を可能にするため、10/100 ネットワークを簡単にスポット チェックしたり、ネットワーク トラフィックを継続的に監視することができます。デバイスに備えられている 2 つの監視用 RJ45 ポートにより全二重の監視が可能になるため、これらのネットワーク ポートの両方がネットワーク モニタ、プロトコル アナライザ、IDS/IPS、またはその他のプローブに接続されているときに、ポートの両方のトラフィックの流れを細かく監視できます。
Teeny Tap は IP アドレスを持ちません。ネットワークから独立しているため、他のユーザーのプレゼンスを検知したときにネットワークをいじるのをやめようとしているユーザーに気付かれることはありません。その一方で、Zero Delay 機能により、タップへの電力供給が停止しても、タップを通るトラフィックの流れに影響はなく、ネットワークの遅延やパケットの損失が起きることはありません。
タップへの電源供給は USB、または同梱の電源装置を使用しますが、冗長性を確保するために、これらの両方を使用することもできます。これは、このような小さいデバイスとしては注目すべき機能です。また、Teeny Tap は、ネットワーク カメラや IP 電話などのイーサネットベース サービス経由の電源を使用することもできます。このように、トラフィックを監視して、コミュニケーションのセキュリティを確保することもできます。
Teeny Tap キットには、タップ、ユニバーサル電源、RJ45 ケーブル (クロスオーバーとストレートスルーが各 2 本)、およびキャリー ケースが含まれています。お使いのネットワーク環境の処理能力を高めたい場合は、NetOptics から出されているその他のネットワーク タップ製品を確認してください。NetOptics の製品ラインは、10 MB ～ 10 GB の銅線ネットワークとファイバ ネットワークの両方に対応し、小規模なオフィス ネットワークから大規模なエンタープライズ環境まで、あらゆる範囲をカバーしています。
価格 : 325 ドル (直販)
Teeny Tap を使用してネットワークを監視する
Teeny Tap を使用してネットワークを監視する (画像を拡大するには、ここをクリックします)

コンピュータを最適化する
DTweak Pro
www.daoisoft.com
IT プロフェッショナル (および一般的なテクノロジ愛好家) が、システムに手を加えて、日常の作業のために可能な限りのパフォーマンスを引き出し、カスタマイズされたエクスペリエンスを堪能したいという願望をいだいていることに疑いの余地はありません。Windows Vista® が実行されているコンピュータのユーザー エクスペリエンスを最適化し、カスタマイズできるツールは数多くあります。その中で、1 つの低価格のオプションが、Daiosoft の DTweak Pro です (Windows® XP および Windows Server® 2003 対応のバージョンも用意されています)。
このアプリケーションでは、さまざまなツールにすばやくアクセスできる数多くのビューが用意されており、Windows Vista をカスタマイズすることもできます。たとえば、Daily Tools セクションでは、レジストリ クリーナ、ファイル クリーンアップ ユーティリティ、レジストリおよびディスクのデフラグ ツール、ハードディスクのパフォーマンス モニタを実行することができます。
DTweak を使用することにより、スタートアップ項目の表示と調整、CPU 情報 (CPU ID、バス スピード、クロック スピードなど) の取得、およびコンピュータ情報 (ベンダー、起動状態、メモリ構成、システムの種類など) の収集を簡単に行うこともできます。さらに、I/O キャッシュ メモリを変更したり、クラッシュしたプログラムや停止したサービスを終了するまでの時間を変えることもできます。
GUI's Tools セクションでは、finger、ping、netstat、nslookup などの使いやすいネットワーク ツールへのリンクばかりでなく、Diskpart とシステムの復元を含む、Windows Vista に組み込みのツールへのリンクも提供されています。その他のネットワーク関連の機能として、最大転送ユニット、TCP/IP TTL、および DNS タイムアウト設定の調整や、QoS パケット スケジューラ サービスの使用帯域幅の制限などがあります。
価格 : 29.95 ドル (ダウンロードによる直販)
DTweak によってシステムをカスタマイズして最適化する (画像を拡大するには、ここをクリックします)

ブック レビュー
Microsoft Exchange Server 2007 Administrator's Companion
www.microsoft.com/mspress
電子メールは、時には扱いにくいものとなります。たとえば、受信するメッセージの流れを実際に制御することは不可能です。SMTP サーバーのキューが減少するまでサーバーを停止することにより、受信メッセージの洪水を回避すると、"メッセージを配信できなかった" という通知をメッセージの送信者が受け取るリスクが生じます。配管システムの例が最もよくあてはまります。水は常に流れており、1 か所のバルブを閉めると、他の場所でパイプが破裂するリスクが生じます。ビジネス全体を円滑に運営するためには、綿密に計画され、使いやすい、柔軟性のある電子メールのインフラストラクチャが不可欠です。
明らかに、Microsoft Exchange Server® 2007 は大量のメールを扱えるように設計されており、組織がかかえる現在のニーズだけでなく将来のニーズも満たせるようにインフラストラクチャをカスタマイズできるようにも設計されています。しかし、Exchange 2007 を展開するにあたり、あまりにも多くのオプションと決定しなければならないことがあります。また、Exchange では電子メールの他にも数多くのものが含まれているため、作業はますます複雑になります。
アーキテクチャと管理について、正しい決定を下せるようになるには、役に立つ参考資料が 1 つか 2 つ必要です。なくてはならない資料の 1 つが『Microsoft Exchange Server 2007 Administrator's Companion』です。
この本は、計画と展開の段階からメンテナンスとセキュリティに至るまで、製品展開のライフサイクル全体をカバーしています。また、Exchange 2007 で利用できるさまざまなクライアント オプションやクライアントの接続オプションについても説明します。まず、さまざまなバージョンの違いの概要を説明し、Exchange 2007 の新機能を紹介します。Exchange Server 2007 のさまざまなアーキテクチャ コンポーネントの概要のすべてについても把握することができます。
次のセクションでは、Exchange の展開計画の作成方法を説明し、ストレージ要件とサーバーおよびプロセッサ要件の計算方法や、フォールト トレランスの追加方法を示します。次に、実際のインストールと展開の方法に関する内容をカバーし、Exchange をインストールするためにサーバーを準備する方法、およびソフトウェアのさまざまなコンポーネントをインストールする方法を示します。また、高可用性を実現するために Exchange サービスをクラスタリングするための詳細な内容も説明しています。
次に、Exchange MMC パネルや新しい Windows PowerShell™ ベースの Exchange 管理シェルなど、自由に使える数多くの管理ツールについて説明します。ここでは、メールボックスの作成からストレージ グループの作成、バックアップ、および復元操作までのすべてを学ぶことができます。このセクションについて、もう 1 つのすばらしい点は、これらの操作を、管理 GUI、および Windows PowerShell のコマンドラインを使用して行う方法の両方を示していることです。
Exchange 2007 には数多くのユニファイド メッセージング機能が備えられており、これによってデータと音声の通信の両方を 1 つのシステムで管理することができます。この本では、ボイス メッセージング、FAX メッセージング、音声ベースの受信ボックスへのアクセスの設定方法と使用方法など、この他にも数多くの機能について説明しています。
この本は、メンテナンスについても深く掘り下げており、基本的なトラブルシューティングの手法とツール、破損および障害からの復旧、およびパフォーマンス チューニングについて書いています。当然、セキュリティはどのユニファイド メッセージング システムにとっても最優先事項ですが、この本でも、展開のセキュリティについて詳しい情報を載せています。セキュリティのポリシーとガイドライン、ウイルス対策とスパム対策機能、および公開キー基盤について学ぶことができます。
最後に、Exchange クライアントを解析し、組織内において他の POP3 およびインターネット メッセージ アクセス プロトコル クライアントをサポートする方法について説明します。全体的に見て、これは Exchange Server 2007 サーバー ユニファイド メッセージング プラットフォームの導入を計画している、すでにこのプラットフォームを管理している、またはただ興味があるかどうかにかかわらず、一般的な参考資料として管理者向けにわかりやすくまとめられた優れた本です。
価格 : 49.99 ドル (定価)
(画像を拡大するには、ここをクリックします)

Greg Steen は技術プロフェッショナルであり、企業家でもあります。また、新製品のファンとも言えます。より簡単な操作、品質保証、および開発に役立つ IT プロフェッショナルのための新しいツールを日夜追い求めています。


SQL に関する Q&A I/O エラー、データベース ミラーリングなど
Paul S. Randal

質問 - 最近、管理しているデータベースに対して定期的に整合性確認を実行するようにしており、ユーザーのクエリによって発生する I/O エラーを検出するために、いくつかの SQL エージェントの警告を追加しました。このデータベースには破損している箇所がないため、確認と警告に関連する実装済みのロジックが機能するかどうかがわかりません。実装したすべての機能が正しく動作することを確認するために、テスト データベース内に破損箇所を作成するにはどうすればよいでしょうか。また、I/O エラーを検出するには、この他にも作業を行う必要がありますか。
回答 - SQL Server® 2000 で、テスト用に破損したデータベースを作成する場合、通常はテスト データベースの sysindexes テーブルから行を手動で削除していました。ただし、SQL Server 2005 では、そのような方法でシステム テーブルを破損させることは非常に困難です。テスト データベースを手動で破損させるための最も良い方法は、データベースがシャットダウンされている状態で、16 進エディタを使用してデータ ファイルを変更することです。この方法を次に示します。
  • データベースをシャットダウンして、データ ファイルがロックされないようにします (ただし、データベースをデタッチしないようにしてください。これは、誤ったページを破損させた場合、そのデータベースを再度アタッチできなくなるためです)。
  • ファイル内の、たとえば 100 ページ (819,200 バイト) 以降のオフセットを選択します。このとき、8192 バイトの境界 (ページの境界) を選択するようにします。これにより、重要なメタデータ ページとアロケーション ビットマップが変更されずに済むため、データベースを起動し、そのデータベースに対して DBCC CHECKDB を実行できるようになります。
  • ファイル内の選択したオフセットに数バイト分 0 を書き込みます。この手法を使用すると、ページ ヘッダーの破損に関する複数のエラーがほぼ確実に発生します。
とは言うものの、破損したテスト データベースを最も速く作成する方法は、他の人が既に作成したデータベースを使用することです。破損した SQL Server 2000 および SQL Server 2005 データベースのサンプル (説明付き) については、私のブログ (go.microsoft.com/fwlink/?LinkId=115151) を参照してください。
I/O エラーを検出するにはどうすればよいかという 2 番目の質問の答えですが、これを行うには、ページのチェックサムを有効にする必要があります。この機能は、I/O サブシステムによって発生したエラーからデータベース ページ全体を保護する方法として、SQL Server 2005 から導入されました。
基本的に、ページがディスクに書き込まれると、最後に SQL Server によってその 8 KB ページ全体のチェックサムが計算され、そのページにスタンプされます。チェックサムが格納されているページがディスクから読み取られると、そのチェックサムは再計算され、既にページに格納されているチェックサムと比較されます。2 つのチェックサムが一致しない場合は、SQL Server 以外の動作が原因でそのページが破損しています。この場合、エラー 824 が発生します。このエラーは、ページの読み取りが発生した接続のエラーとして表示され、SQL Server エラー ログと Windows® のアプリケーション イベント ログに記録されます。
SQL Server 2005 と SQL Server 2008 で作成されるすべてのデータベースでは、ページのチェックサムが既定で有効になります。ただし、SQL Server の以前のバージョンからアップグレードされたデータベースの場合は、手動でこのチェックサムを有効にする必要があります。次のコードを使用すると、ページのチェックサムを有効にすることができます。
ALTER DATABASE mydb SET PAGE_VERIFY CHECKSUM;

ヒント : 既定の SQL Server ポートを変更する
既定では、SQL Server インスタンス用に構成されているポートは 1433 です。あるインスタンスによってこのポートが使用されると、別のインスタンスはこのポートを使用できなくなります。したがって、ネットワーク上で TCP を使用してリッスンする 2 番目の (名前付き) インスタンスをインストールする場合は、別のポートが必要になります。また、使用されているポートをわかりにくくするために、管理者がポートを変更する場合もあります (ただし、ポート スキャナによって簡単にポートが検出されてしまうため、この方法はあまり使用されません)。もちろん、その後、異なるポートを使用するようにクライアントを構成する必要があります。これを行うための一般的な方法は 3 つあります。
管理者がインスタンスのポートを 5555 に変更した場合、1 つ目の選択肢は、MyServername,5555 という構文を使用して、接続先のコンピュータ名と共にインスタンスのポート番号を指定する方法です。そのポートが再度変更された場合は、クライアントも再度 connectionStrings を変更する必要があります。
2 つ目の選択肢は、クライアント上で構成された SQL Server の別名を使用する方法です。別名以外に、サーバー名、ポート名、およびプロトコルも指定する必要があります。構成後は、サーバー名と同じようにその別名を使用して、データベース インスタンスに接続できます。この方法の利点は、設定がレジストリに格納されるため、ドメイン管理者がサーバーの構成に加えた変更を展開できることです。
3 番目の選択肢は、ユーザーが名前付きインスタンスのインスタンス名のみを知っていて、connectionString 内で "コンピュータ名\インスタンス名" を使用して名前を指定する場合に、SQL Server Browser サービスを使用する方法です。SQL Server 2000 では、このサービスは実行されるサービスの一部として既に実装されていますが、SQL Server 2005 では別個のサービスとして構築されました。SQL Server Browser サービスは、コンピュータ上のインスタンスを検出するだけでなく、要求されたインスタンスに適したポート番号を使用して、ポート 1434 に対するユーザー データグラム プロトコル (UDP) の着信要求に応答します。また、クライアントのリダイレクトを有効にしたり、透過的な接続をサポートします。
—Jens K. Suessmeyer、データベース コンサルタント (マイクロソフト)

質問 - データベース内の断片化をすべて解消するために、SQL Server 2005 Enterprise Edition SP2 上で実行されている運用データベース内のすべてのインデックスを再構築する、夜間のメンテナンス プランを構成しましたが、これによってデータベースが過度に拡張されることがわかり、ディスク上の空き領域も少なかったことから、余分な空き領域をすべて圧縮する操作を追加しました。すると、再構築操作が機能しなくなったようです。何が起こっているのでしょうか。
回答 - これは、メンテナンス プランを構成する際によく直面する問題です。圧縮と拡張を繰り返すサイクルに陥っているのです。
インデックスが再構築されると、既存のインデックスが削除される前に、そのインデックスの新しいコピーが作成されます。この手順を完了するには、データベース ファイル内に空き領域が必要です。通常は、現在のインデックスによって使用されているものと同じくらいの領域が必要になります。SQL Server 2000 では、インデックス行の並べ替えを実行する場合でも空き領域 (インデックスのサイズの約 20%) が必要でしたが、SQL Server 2005 では、単純なインデックスの再構築を実行する場合、この領域は不要になりました。
管理者は、インデックスの再構築時に作成された余分な空き領域を取り除くために、メンテナンス プラン内の再構築操作の後に圧縮操作を追加することがあります。ただし、あまり広く知られていることではありませんが、この圧縮操作のアルゴリズムの性質が原因で、インデックスの断片化が発生します。つまり、新しく再構築および最適化されたインデックスはすぐに断片化し、最初に行った再構築の効果がなくなってしまいます。
次回インデックスの再構築が発生したときに、データベース ファイルが再度拡張されることを考えると、データベース内の余分な空き領域を保持し、さらに圧縮操作を実行しないことをお勧めします (また、頻繁にデータベース ファイルが拡張および圧縮されると、OS レベルでファイルの断片化が発生します。これにより、インデックスが断片化した場合と同じように、パフォーマンスが低下します)。
最後に 1 つ、インデックスを再構築する頻度を減らすことを検討するとよいでしょう。以前 SQL Server 2000 に関する記事で紹介した DBCC INDEXDEFRAG や、新しい SQL Server 2005 と SQL Server 2008 の ALTER INDEX REORGANIZE 構文など、別の方法を使用することもできます。
インデックスの断片化に関する説明と、断片化を解消するタイミングに関するガイダンスが記載された、便利なホワイト ペーパーも公開されています (go.microsoft.com/fwlink/?LinkId=115154)。このホワイト ペーパーは SQL Server 2000 用に執筆されたものですが、その概念は現在でも変わっていません。

質問 - 現在組織で障害回復戦略を評価しており、データベース ミラーリングが当社の状況に適した方法であると考えています。保護しようとしているサーバーには、(以前に実施したサーバー統合プロジェクトの結果) 関連し合っていない多くのデータベースが格納されており、これらすべてのデータベースにデータベース ミラーリングを使用する予定です。どれぐらいの数のデータベースをミラーリングすると、パフォーマンスが低下し始めるのでしょうか。
回答 - 質問への回答として非常によく使用する表現ですが、それは "場合によります"。公開されているガイドラインでは、1 つのインスタンスにつき 10 個を超えるデータベースをミラーリングしないことが推奨されていますが、この 10 という数字は大部分のユーザーに当てはまる最大値を大まかに推測したものです。実際に使用しているハードウェア構成と照らし合わせて、次の要因を考慮する必要があります。
  • プリンシパル インスタンスとミラー インスタンスで使用できるメモリのサイズ (これは同じサイズであるのが理想です)
  • プリンシパル インスタンスとミラー インスタンスの処理能力 (これも同じであるのが理想です)
  • ミラー インスタンス上の I/O サブシステムで使用できる帯域幅の広さ (これは、プリンシパル インスタンス上の I/O サブシステムと同じであるのが理想です)
  • 各データベース上のワークロードによって生成されるトランザクション ログの量
  • プリンシパル インスタンスとミラー インスタンスとの間の通信に使用できるネットワーク帯域幅の広さ
最後の 2 つの要因は最も重要です。2 つのインスタンス間の通信に使用できるネットワーク帯域幅の広さが十分でないことが原因で、ミラーリングされるすべてのデータベースから 1 秒あたりに生成されるトランザクション ログの量に対処できない場合、プリンシパル データベースのパフォーマンスは低下します。SQL Server 2008 では、ログ ストリームの圧縮によって、この負荷を若干軽減できます。
次に考慮すべき重要なことは、ミラーリングに必要なメモリとスレッドの量です。ミラー データベースごとに、1 つのスレッドと若干のメモリが必要です。処理能力の低いサーバーでは、大量のデータベースをミラーリングすると、通常のワークロードと合わせて、サーバーへの負荷が非常に大きくなる場合があります。
また、データベース ミラーリングの実行方法も検討する必要があります。同期モードでは、すべてのトランザクション ログ レコードがミラー データベースのトランザクション ログにコピーされるまで、プリンシパル データベース上のトランザクションをコミットできません。したがって、ネットワーク上のトラフィックが多すぎることによって遅延が発生した場合、プリンシパル上でワークロードのパフォーマンスに関する問題が発生する可能性があります。
非同期モードでは、待機時間は発生せず、プリンシパル上でトランザクションをコミットできますが、ミラーへの送信を待機するトランザクション ログの量が、ネットワークの遅延によって増加する可能性があります。これにより、トランザクション ログのサイズに関する問題が発生する場合があります。なお悪いことに、障害が発生した場合、未送信のすべてのトランザクション ログが失われます。したがって、未送信のトランザクション ログの数が多いほど、回復時にデータが失われる可能性が高くなります。
シナリオごとに環境は大きく異なりますが、実際の運用環境におけるいくつかの興味深い例を紹介します。たとえば、ある環境では 150 個のデータベースを保有しており、どのデータベースの使用率も非常に低く、さらにすべてのデータベースが同時に使用されることはありませんでした。このため、150 個のデータベースは、すべて問題なくミラーリングされていました。
これに対して、ある環境では、負荷の高いデータベースを 3 つのみ保有していましたが、ネットワーク接続が不安定でした。このシナリオでは、辛うじて 1 つのデータベースをミラーリングしたところで、ネットワーク帯域幅の不足によってワークロードのパフォーマンスが低下し始めました。
まずは、生成されるログの量を計算することが重要です。現在のネットワーク帯域幅で、ミラーリングする必要があるデータベースの数がサポートされるようであれば、問題ないでしょう。運用環境に移行する前に構成をテストし、特にデータベース メンテナンスなど、トランザクション ログが生成される可能性のあるすべての操作を考慮するようにしてください。

Paul S. Randal は SQLskills.com の代表取締役であり、SQL Server MVP でもあります。1999 年から 2007 年までは、マイクロソフトの SQL Server ストレージ エンジン チームに所属していました。また、『DBCC CHECKDB/repair for SQL Server 2005』を執筆し、SQL Server 2008 の開発時にはコア ストレージ エンジンを担当していました。Paul は障害回復、高可用性、およびデータベース メンテナンスの専門家であり、カンファレンスで定期的に発表を行っています。彼のブログは SQLskills.com/blogs/paul で公開されています。


ユーティリティ スポットライト Windows Vista Upgrade Advisor
Lance Whitney

時機到来です。 他のアップグレードと同様に、組織内のシステムの Windows Vista® へのアップグレード計画をスタートさせましょう。しかし、ここで疑問が生じます。ネットワーク クライアントはハードウェアとソフトウェアの要件を満たしているのだろうか? どのような互換性の問題が予想されるのだろうか? マイクロソフトでは、このような疑問に対する答を見つけられるように、Windows Vista Upgrade Advisor を無償で提供しています。このユーティリティは、PC にインストールされているすべてのハードウェアとソフトウェアをスキャンし、アップグレードが可能かどうかを判断します。アップグレードが可能であると判断した場合、Upgrade Advisor は Windows Vista の最適なバージョンを推奨し、アップグレード前に対処すべき問題がある場合は、それを指摘します。
Upgrade Advisor がスキャンを行うのに、通常、数分かかります。スキャンの実行中は、画面に Windows Vista の各バージョンの機能を比較した一覧が表示されます。また、Ultimate、Home Premium、Business、または Home Basic の中から特定のエディションを選択して、それぞれの簡単な説明と優れた機能の一覧を表示させることもできます。スキャンの完了後、PC が Windows Vista にアップグレード可能であるかどうか、および推奨するバージョンが [レポートの詳細] ウィンドウに表示されます。表示される内容は次のとおりです。
システム要件 ハードウェア (CPU、RAM、ビデオ メモリ、および CD/DVD ドライブ) の要件が満たされているかどうかが表示されます。要件が満たされていない場合は、たとえば追加する必要のあるメモリ容量など、PC をアップグレードするために必要な項目の詳細が表示されます。
デバイス モデム、プリンタ、スキャナ、サウンド カード、モニタ、ビデオ カードなど、すべての外付けデバイスとドライバを診断します。デバイスが互換性テストに合格しなかった場合、たとえば、メーカーの Web サイトから最新のドライバをダウンロードするなど、問題を解決するのに必要な操作ついての説明が表示されます。便宜上、Web サイトへのリンクが提供されます。
Upgrade Advisor は、既知の問題および推奨する解決方法を報告します。
Upgrade Advisor は、既知の問題および推奨する解決方法を報告します。 (画像を拡大するには、ここをクリックします)
プログラム インストールされているソフトウェアを分析します。各アプリケーションがそのまま Windows Vista でも動作するか、どのアプリケーションで Windows Vista との互換性の問題が発生するか、または互換性テストに合格するためにアップグレードが必要であるかどうかが示されます。
Ultimate など、Windows Vista の上位バージョンに対してコンポーネントのいずれかが互換性テストに合格しなかった場合は、最初の画面に戻って、Business など、他のバージョンを選択できます。こうすることで、お使いの PC が選択したバージョンに対してすべての要件を満たしているかどうかが調べられます。
最後に [タスク リスト] に、PC のハードウェア構成と、Windows Vista のインストール前後に行う必要がある作業項目の一覧が表示されます。スクリーンショットが示しているように、この画面には、前の画面の情報が要約されており、追加の推奨事項が提供されます。タスク リストは、印刷したり、HTML ファイルとして保存したりすることができます。
Upgrade Advisor は 32 ビット版の Windows Vista または Windows® XP Service Pack 2 で動作し、Microsoft® .NET Framework 2.0 および MSXML 6.0 がインストールされている必要があります。ツールの詳細情報およびダウンロードについては、microsoft.com/windows/products/windowsvista/buyorupgrade/upgradeadvisor.mspx を参照してください。

Lance Whitney は、IT コンサルタントであり、トレーナーであり、テクニカル ライターでもあります。Windows のワークステーションおよびサーバーをカスタマイズすることに数えきれないほどの時間を費やしてきました。元々はジャーナリストでしたが、15 年前、IT 業界への転向を実現しました。


SharePoint の内部 サイトの管理を分散する
Pav Cherny

この記事で使用しているコードのダウンロード: SharePoint2008_06.exe (1160KB)

Microsoft Windows SharePoint Services (WSS) 3.0 と Microsoft Office SharePoint Server (MOSS) 2007 では、管理とセキュリティの柔軟なモデルがサポートされています。IT 組織はこのモデルを使用して、Web サーバーやデータベース サーバーなどのインフラストラクチャ コンポーネントの制御を一元化しながら、ホストする
サイト コレクションやサイトの制御を分散することができます。SharePoint® インフラストラクチャの管理を一元化すると、保守作業に伴うオーバーヘッドを削減したり、ビジネス ロジックを統合したりすることができます。また、SharePoint リソースへの単一のアクセス ポイントを提供し、テクノロジへの不要な投資を避けることもできます。
一方、サイトの管理を分散すると、個々の部門がそれぞれ所有している SharePoint リソース (サイト コレクション、サイト、ドキュメント ライブラリ、リスト、ワークフロー ソリューションなど) を自分たちで制御できるようになります。ただし、サイトの管理を各部門に委任すると、IT 部門による保守作業が複雑になるというデメリットがあります。たとえば、使用している環境内のサイト コレクションやサイトにアクセスできない場合、一元管理されたインフラストラクチャの、リソース利用状況、期限切れの SharePoint サイト、および古くなったコンテンツをどのようにして追跡すればよいのでしょうか。
この記事では、WSS 3.0 のセキュリティ モデルについて説明します。具体的には、SharePoint インフラストラクチャに対する一元化された管理者レベルの制御を維持しながら SharePoint サイトに対する管理者レベルの制御を個々の部門に委任すると、どのようなメリットと影響があるかについて説明します。委任されたサイト管理のしくみを説明し、サイト レベル、リスト レベル、およびアイテム レベルでの、アクセス権とセキュリティによるトリミングが、安全でユーザー フレンドリな作業環境の維持にどのように役立つかを説明します。また、Web ファーム管理者が、SharePoint に対する昇格された権限なしで、必要なサイトの統計データにアクセスする方法も紹介します。
この記事で説明している内容をテスト ラボで確認するには、technetmagazine.com で、この記事付属のリソースをダウンロードしてください。付属リソースには、Windows Server® 2008 ベースの Web ファームでの展開に関する詳細な説明が含まれており、この Web ファームは、複数の部門を持つ企業の運用環境を適切に反映したものになっています。

SharePoint インフラストラクチャとサイト コレクションの管理
SharePoint インフラストラクチャは、単一サーバーでの展開または Web ファームでの展開に基づいて構築することができます。実際、企業では、この両方を使用することがよくあります。単一サーバーでの展開は、手軽で簡単なコラボレーション ソリューションを必要とする個々の部門に適しています。この展開では、パフォーマンスと信頼性の要件は最小限に抑えられます。また、ユーザーが (多くの場合、ワークステーションのハードウェアに展開されている) 自部門の SharePoint サーバーを使用できない場合にも理解を示す傾向があります。というのも、システムの保守は、その部門で行う必要があることですが、その部門に所属するユーザーは IT 管理者ではないからです。
IT 部門が保守を行うサーバー リソースの場合、状況は一変します。パフォーマンスと信頼性は重要な要素となり、多くの場合、サービス レベル契約 (SLA) への準拠を確実にするために高可用性ソリューションの展開が必要となります。負荷分散された Web ファームでの展開、SQL Server® フェールオーバー クラスタ、および記憶域ネットワーク (SAN) に格納されたデータベースは、企業のパフォーマンス ニーズと高可用性ニーズを満たすのに役立ちます。このアーキテクチャの詳細については、図 1 を参照してください。
図 1 SQL Server フェールオーバー クラスタと SAN を使用した SharePoint インフラストラクチャ
図 1 SQL Server フェールオーバー クラスタと SAN を使用した SharePoint インフラストラクチャ (画像を拡大するには、ここをクリックします)
図 1 に示すように、一元管理された SharePoint インフラストラクチャのリソースを保守するためには異なる役割を担った数名の管理者が連携する必要がありますが、各管理者は環境を異なる観点から捉えています。たとえば、サイト コレクションの管理者は、インフラストラクチャのサーバーを意識しません。サイト コレクションの管理者は、標準的な SharePoint ユーザー インターフェイスを使用して作業を行います。このインターフェイスは、オフィス内にある WSS 3.0 を実行しているワークステーション コンピュータでサイトをホストしても、データ センター内にある Web ファームでサイトをホストしても変わりません。
データベース管理者と SAN ストレージ エンジニアも、SharePoint インフラストラクチャを意識しません。このような管理者 (データベース管理者と SAN ストレージ エンジニア) にとっては、SharePoint データベースは他の SQL Server データベースとなんら変わりはなく、SQL Server フェールオーバー クラスタの論理ユニット番号 (LUN) も他の LUN となんら変わりはありません。SharePoint インフラストラクチャに最も直接的に関与しているのは Web ファーム管理者ですが、Web ファーム管理者は、サイト コレクション、データベース、または LUN を制御することはできません。
各部門のサイト コレクション管理者は、概してインフラストラクチャの詳細について知らない、と言って差し支えないでしょう。というのも、サイトを準備し、部門内のチームやグループにアクセス権を委任するために、このような詳細を把握する必要ないからです。新しいサイトを作成して共同作業を開始するのは簡単で、問題 (SAN テクノロジに伴う高いストレージ コストなど) が頭に浮かぶことはめったにありません。
プロジェクトや構想ごとに、新しいチーム サイトが作成され、期限切れのサイトが残存し、古くなったコンテンツが削除されないという状況により、SharePoint 環境は、目覚ましい速度で急激に拡大し、システム管理者が無視できなくなる規模に達するまで、そう時間はかかりません。たとえば、Microsoft IT が 2006 年に単純化構想を打ち出す前のことですが、マイクロソフトの社内 SharePoint 環境には、180,000 を超えるサイトが存在していたことがありました。
サイト コレクションの管理者を教育すると、一元管理された SharePoint インフラストラクチャで問題を抑制するのに役立ちます。サイト コレクションのクォータとロックを適用するのも有効ですが、こうした方法は、貴重なストレージ リソースやバックアップ リソースを浪費する古くなったチーム サイトやコンテンツには、あまり効果的ではありません。
古くなったコンテンツが存在すると、必ずしもサイト コレクションがクォータ制限を超えるというわけではありません。もちろん、SharePoint 3.0 サーバーの全体管理サイトの使用確認と削除の機能を使用して、指定した時間がたつとサイト コレクションの所有者に電子メール通知を送信して使用されていないサイト コレクションを自動的に削除するように SharePoint を構成することもできますが、この機能は個々のサイト レベルでは機能しません。サイト コレクションには、現在使用中のサイトと現在既に使用されていないサイトが含まれることがありますが、サイトの使用確認と削除の機能は、サイト レベルでは機能しません。
サイト コレクションへのアクセス権がなくても、ドキュメントやリスト アイテムの最終更新日を確認して、使用されていないサイトや古くなったコンテンツを特定できる方法については、後で説明します。このレポート機能は、既定の設定で使用できるものではありませんが、さいわい実装するのは難しくありません。

分散化された SharePoint サイト管理
SharePoint サイトの管理権限は非常に簡単に委任できます。SharePoint 3.0 サーバーの全体管理サイト、コマンド ライン ツール (Stsadm.exe)、または独自の準備ツールを使用して、Web アプリケーション、管理パス、およびサイト コレクションをインフラストラクチャ内に作成することができます。Web ファーム管理者は、サイト コレクションの作成時に、サイト コレクションの管理者と代理の管理者を指定できます。このサイト コレクションの管理者と代理の管理者には、標準のドメイン ユーザーを指定することも可能です。このような管理者には、Web ファームや他のインフラストラクチャ サーバーに対する管理者権限は必要ありません。また、サイトの管理タスクは、Web ブラウザを使用して、SharePoint ユーザー インターフェイスから直接実行します。
図 2 は、委任されたサイト管理を示しています。この図は、付属リソースのワークシートに記載されている順を追った説明に基づいたものです。この例では、Web ファーム管理者は、人事部門用 (http://sharepoint/hr) と IT 部門用 (http://sharepoint/it) に別個のサイト コレクションを準備しました。
図 2 委任された SharePoint サイト管理
図 2 委任された SharePoint サイト管理 (画像を拡大するには、ここをクリックします)
人事部門サイト コレクション管理者と IT 部門サイト コレクション管理者は、SharePoint ユーザー インターフェイスの [サイトの操作] メニューの [サイトとワークスペース] をクリックして、サブレベル サイトを作成し、親サイトの権限を適用するか、サブレベル サイトの新しい管理者権限とユーザー権限を定義することができます。すべてのサイトは同じ SharePoint 環境でホストされていますが、明示的に別途構成しない限り、Web ファーム管理者はトップレベル サイトやサブレベル サイトにアクセスできず、人事部門サイト コレクション管理者は IT 部門のサイトにアクセスできず、IT 部門サイト コレクション管理者は人事部門のサイトにアクセスできないことに注意してください。
サイト コレクションやサイト階層のデザインは、組織の要件によって異なります。図 2 の例では、http://sharepoint/hr と http://sharepoint/it の上位にマスタ サイトを作成しませんでした。つまり、http://sharepoint というパスにサイト コレクションは存在しません。しかし、このパスにサイト コレクションを作成したり、他の管理パス (http://sharepoint/sites/hr や http://sharepoint/sites/it など) を使用したりすることは、簡単にできます。
また、人事部門と IT 部門用に個別の Web アプリケーションを作成して、より直感的なベース URL (http://hr や http://it など) を設定し、両部門用の汎用的なポータル サイトを準備し、ロールアップ Web パーツを使用してサブレベル サイトの情報をマスタ サイトに表示することもできます。個別のサイト コレクションを用意すると、自律的な管理が容易になり、部門情報へのアクセスを制限するのに役立ち、マスタ ページ、ページ レイアウト、テンプレート、Web パーツ、およびナビゲーション コントロールを各部門でカスタマイズできるようになります。また、別個のサイト コレクションは、機密データを他のサイト コレクションやコンテンツ データベースとは別の専用のコンテンツ データベースに格納するために使用することもできます。

ロール、サイトの権限、およびセキュリティによるトリミング
サイト コレクションが作成され、管理者権限が委任されると、サイト コレクションの管理者は、トップレベル サイトを開き、[サイトの操作] メニューの [サイトの設定] をクリックしてサイト コレクションを管理できます。実行できる管理作業には、サイト コレクション内の全サイトに対する完全な権限を持った他のサイト コレクション管理者を追加 (または削除) すること、グループを作成すること、作成したグループをロールと関連付けること、および作成したグループにユーザーを追加して読み取りや投稿者の権限を与えることなどがあります。また、サブレベルのグループ サイトやチーム サイトを準備することもできます。
SharePoint に対する権限をユーザーに個別に与えることもできますが、特定のロールに基づいて SharePoint グループを作成することをお勧めします。たとえば、SharePoint には、閲覧者、投稿者、および所有者の各ロール用の 3 つのグループが既定で組み込まれています。閲覧者は読み取り専用のアクセス権を持ち、投稿者はリストやドキュメント ライブラリにアイテムを追加したり Web ページを個人用に設定したりすることが可能で、所有者はフル コントロールの権限を持ちます。
SharePoint の注目すべき特色の 1 つは、ユーザー ロールに基づいてセキュリティによるトリミングが実行されるということです。つまり、ユーザー インターフェイスには、そのユーザーが実際にアクセスする権限を持っているリンクやアイテムのみが表示されます。あるユーザーがリストまたは特定のリスト アイテムなどのリソースにアクセスできないように設定すると、このユーザーのユーザー インターフェイスでは、そのリストやアイテムが表示されなくなります (リストの場合は [リストの設定] で明示的に権限を構成し、リスト アイテムの場合はそのアイテムのコンテキスト メニューの [権限の管理] を使用することで、リソースへのアクセスを拒否します)。ユーザーがアクセスする権限がないアイテムの URL をブラウザで直接指定すると、"エラー: アクセス拒否" というページが表示されます。
図 3 は、セキュリティによるトリミングが実際に行われている画面を示しています。人事部門サイト コレクション管理者は完全な権限を持っており、[サイトの操作] メニューにアクセスして、管理タスクを実行することができます。一方、人事部門の閲覧者は、このサイト コレクションに対して読み取り専用の権限しか持っていないので、ユーザー インターフェイスに、[サイトの操作] メニューは表示されません。
図 3 SharePoint インターフェイスでユーザー ロールに基づいてセキュリティによるトリミングが行われているようす
図 3 SharePoint インターフェイスでユーザー ロールに基づいてセキュリティによるトリミングが行われているようす (画像を拡大するには、ここをクリックします)
セキュリティによるトリミングは、アクセスできない機能、リンク、およびアイテムが非表示になるので、役に立ちます。しかし、Web ファーム管理者もアクセス権がないと SharePoint ユーザー インターフェイスを使用してサイトやサイトのリソースを表示できないことになります。アクセス権がないリソースは Web ページや Web パーツに表示されません。また、SharePoint エンタープライズ検索では、クエリを送信しているユーザーの ID に基づいて、セキュリティによるトリミングがクエリ時に実行されるので、アクセスできないリソースは検索結果にも表示されません。

コマンド ラインについて
昇格された権限を持っていなくて、必要な情報をサイト コレクション レベルで表示する方法がグラフィカル ユーザー インターフェイスで提供されない場合は、コマンド ライン ツール Stsadm.exe を使用すると問題が解決することがあります。たとえば、http://sharepoint という Web アプリケーション内のサイト コレクションと所有者をすべて表示するには、
Stsadm -o enumsites -url http://sharepoint
というコマンドを使用し、その後、次のコマンドを使用すると、すべてのサブサイトを表示できると考えるかもしれません。
Stsadm -o enumsubwebs -url <サイト コレクション>
しかし、通常、Web ファーム環境では、上記のように Stsadm.exe を実行すると、データベースへのアクセス権がないことを示すエラー メッセージが表示されます。Stsadm.exe を実行しているユーザーが Web ファーム管理者であり、SharePoint 3.0 サーバーの全体管理のサイト コレクションを管理できるユーザーであっても、サイト コレクションを列挙することはできません。SQL Server へのアクセス権がない状態で Web ファームで Stsadm.exe を実行すると、次のようなエラー メッセージが表示されます。
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o enumsites -url http://sharepoint
<Sites Count="2">
<Site Error="このログインで要求されたデータベース &quot;WSS_Content&quot; を開けません。ログインに失敗しました。&#xD;&#xA;ユーザー 'CONTOSO\SPAdmin' はログインできませんでした。">
<Site Error="このログインで要求されたデータベース &quot;WSS_Content&quot; を開けません。ログインに失敗しました。&#xD;&#xA;ユーザー 'CONTOSO\SPAdmin' はログインできませんでした。"/>
SharePoint 3.0 サーバーの全体管理サイトは、SharePoint サーバーの全体管理 v3 アプリケーション プールに関連付けられたシステム アカウント (CONTOSO\WssConfigAdmin など) のコンテキストで SharePoint データベースにアクセスしますが、Stsadm.exe はログオンしているユーザー (CONTOSO\SPAdmin など) のコンテキストで実行されます。そのため、Web ファーム管理者に対して、上記のエラー メッセージが表示されます。SQL Server のコンテンツ データベースに対する db_owner 権限を使用中のログイン アカウントに与えると、このアカウントで Stsadm -o enumsites -url http://sharepoint コマンドを実行できるようになりますが、サイト コレクション内のサブレベル サイトを列挙できるようにはなりません。Stsadm -o enumsubwebs -url <サイト コレクション> というコマンドを実行すると、"アクセスが拒否されました" というメッセージが表示され (HRESULT: 0x80070005 (E_ACCESSDENIED) による例外です)、振り出しに戻ってしまいます。しかし、より適切で成功する可能性が高く、SQL Server に対する昇格された権限が不要の方法があります。

コンテンツ データベースに格納されているサイト情報
標準的な SharePoint インターフェイスやツールを使用しても、必要な情報を取得できない場合は、SharePoint のコンテンツ データベースに直接アクセスする必要があります。ですが、この方法は最終的な手段として使用する必要があることに注意してください。コンテンツ データベースでは独自のスキーマとデータベース構造が使用されています。マイクロソフトでは、ユーザーがデータベースを直接操作するのを防ぐため、WSS 3.0 SDK では、これらについて部分的にしか説明していません。必要な情報へのアクセスには、可能な限り、SharePoint ユーザー インターフェイス、コマンド ライン ツール、オブジェクト モデル、または Web サービスを使用してください。
データベースに直接アクセスする以外に方法がない場合は、少なくとも、読み取り専用のアクセス権を使用するという制約を課したうえで、この方法を用いる必要があります。データベース スキーマやデータベース構造を変更することはサポートされていません。変更すると、深刻な問題が発生することがあり、サイト コレクションをバックアップから復元したり、SharePoint Web ファームを再インストールしなければならなくなる場合があります。
コンテンツ データベースに直接アクセスするレポート ソリューションの代替方法として考えられるのは、サイト コレクションの構成で Web ファーム管理者アカウントを代理所有者として指定することです。Web ファーム管理者は、SharePoint 3.0 サーバーの全体管理サイトでこの手順を実行できます。[アプリケーション構成の管理] ページの [SharePoint サイトの管理] に、この手順に対応する [サイト コレクションの管理者] リンクがあります。
サイト コレクションの代理所有者は、Web ブラウザでサイト コレクションを開き、サイトの設定を表示して、[サイトの管理] の [サイト利用状況のレポート] リンクをクリックすることができます (ただし、SharePoint 3.0 サーバーの全体管理で、利用状況の分析処理が有効になっていることが前提条件となります)。SharePoint サーバーの利用状況データをログ ファイルに記録して追跡する場合は、[サーバー構成の管理] ページの [ログおよびレポートの作成] の設定を参照してください。既定では、サイト利用状況のレポートの機能は無効になっています。
しかし、多数のサイト コレクションが存在する環境や、要件が厳しいため必要な権限を Web ファーム管理者に与えることができない環境では、サイト利用状況のレポートを個々のサイト コレクションごとに手動で作成するのは実用的ではありません。より実用的な方法は、コンテンツ データベースに格納されているすべてのサイト コレクションとサイトを重要な統計データ (アイテムの数、全アイテムのサイズを合計した値、アイテムの最終更新日など) と共に表示する、簡単な ASP.NET レポート アプリケーションを実装することです (図 4 参照)。
図 4 サイトの統計データをコンテンツ データベースから直接取得する
図 4 サイトの統計データをコンテンツ データベースから直接取得する (画像を拡大するには、ここをクリックします)
SharePoint サーバーの全体管理 v3 アプリケーション プール アカウントを使用してこのアプリケーションを実行すると、SQL Server に対して昇格された権限がなくてもコンテンツ データベースにアクセスできます。前述のとおり、サーバーの全体管理アカウントは、SQL Server に対する必要な権限を既に持っています。
付属リソースには、SQL Server のコンテンツ データベースに対して SELECT クエリを使用する簡単なレポート ソリューションと、このソリューションを Web サーバーに展開するための順を追った説明が含まれています。このアプリケーションには、セキュリティ チェックが一切実装されていないことに注意してください。このソリューションは、匿名認証を使用して実行されます。
サーバーの全体管理アカウントはコンテンツ データベースへのアクセスに必要なセキュリティ コンテキストを提供するので、ユーザーを認証する必要はありません。ソリューションの Web サイトには、Windows Server 2008 の Windows® ファイアウォールによってブロックされる、カスタム ポートを使用したので、Web アプリケーションを開くことができるのはローカル ユーザーのみです。これで、私のテスト環境でのセキュリティ要件は満たされましたが、運用環境では、Windows 認証を有効にし、ASP.NET アプリケーションの仮想ディレクトリに対する制限されたアクセス権を構成するなど、セキュリティを強化する必要があります。

まとめ
SharePoint は、柔軟なサイト コレクションとサイト管理機能を提供します。これにより、各組織のニーズに応じて、サイトの管理を分散しながら SharePoint インフラストラクチャを一元管理することができます。統合された環境は、コスト削減に役立ち、部門内や部門間の情報共有を促進し、的確な専門知識を適用することで高度なセキュリティ、信頼性、およびスケーラビリティを備えた環境を保守するための基盤を提供し、社内ネットワーク内のサイトや SharePoint リソースへの単一のアクセス ポイントをユーザーに提供するので、一元管理されたインフラストラクチャは、あらゆる規模の組織において役立ちます。
また、個々の部門や事業単位は、インフラストラクチャが一元管理されても、それぞれが担当する SharePoint リソースを引き続き制御することができます。Web ファーム管理者はサイト コレクションの管理者を指定することができ、指定された管理者は、IT 部門のサポートを必要とすることなく、自分の担当範囲内でサイトの管理タスクを実行することができます。
しかし、Web サイトの制御権を各部門に委任すると、Web ファーム管理者は、標準的な SharePoint 機能やツールを使用してインフラストラクチャのリソース利用状況を監視することができなくなります。コンテンツ データベースにクォータを適用したり、サイト コレクションの管理者に電子メール通知を送信したり、レポート目的で利用状況データを追跡したりすると、問題を軽減するのに役立ちますが、SharePoint インフラストラクチャを効率的に管理するには、Web ファーム管理者は、必要なサイト メタデータを読み取り専用でコンテンツ データベースから直接取得する追加のツールを使用する必要があります。
このようなツールとして使用できるものには、SQL Server 2005 Reporting Services や、これと同様のエンタープライズ レベルのレポート ソリューションなどがあります。付属リソースの例で紹介したように、SQL Server の SELECT クエリを使用して必要な情報を取得することもできます。

Pav Cherny は、主にコラボレーションとユニファイド コミュニケーションに関するマイクロソフト テクノロジを扱う IT 専門家であり、IT 関連書籍の執筆も行っています。これまでに、IT の運用とシステム管理についてのホワイト ペーパー、製品マニュアル、書籍などを執筆してきました。Pav は、ドキュメント管理とローカライズ サービスの専門企業 Biblioso Corporation の代表取締役です。


Windows PowerShell 見栄えの良い出力
Don Jones

多くの人が見栄えの良い出力を作成するスクリプトを望んでおり、よく、テーブルのような出力を作成するのに最も良い方法についてたずねられます。これには、実際にいくつかの方法があります。最初の手順では、書式設定された形で表示するデータを次の名前の付いた変数に変換するスクリプトを書きます。
$data1、$data2、および $data3。これで、データの書式設定を始める準備が整いました。

テキストの特徴
Web 上
今月の Windows PowerShell のコラムに紹介されている手法の簡単なデモンストレーションをご覧になりたい方は、technetmagazine.com/video にアクセスして、Don Jones によるこれらのコマンドレットの実行を参照してください。

この作業を行う際に最も一般的に取られる方法は、VBScript、Perl、KiXtart、またはその他のテキスト指向の言語などで作業する場合と同じになる傾向があります。画面に列のヘッダーのセットを書くことから始めます。
Write-Host "ColumnA'tColumnB'tColumnC"
Windows PowerShellTM では、"`t" はタブ文字を挿入する特別なエスケープ シーケンスであることに注意してください。データが $data1、$data2、および $data3 であることを考慮に入れると、テーブルの各行を書くには、いくつかの選択肢があります。1 つは、変数を二重引用符で囲まれたコンテンツに置換するシェルの機能を利用して、変数を記述する方法です。
Write-Host "$data1't$data2't$data3"
もう 1 つの、より魅力的な方法は –f 演算子を使用する方法です。この手法では、データから書式設定を分離して、読みやすく、維持が簡単なコード行を作成します。
Write-Host "{0}'t{1}'t{3}" –f $data1,$data2,$data3
しかしながら、これらの方法には重大な問題があります。まず、コンソール ウィンドウで固定されたタブ ストップを使用することにより、おかしな書式設定になってしまう可能性があります。たとえば、あるテーブルの最初の列の行に 20 文字分のデータが含まれていると、その行の書式設定全体がおかしくなってしまいます。また、Write-Host を使用してテキストを出力するため、コンソール表示の制限の影響を受けてしまいます。
ファイルや他の形式で出力する簡単な方法はなく、あまりお勧めしません。最も重要なことは、このテキストベースの方法では、私が専門としている本質的なオブジェクトベースのシェルが完全に無視され、Windows PowerShell のすばらしい技法や機能を活用できない点です。

Windows PowerShell の特徴
Windows PowerShell はオブジェクト指向のシェルです。つまり、理想を言うならば、扱う対象をすべてオブジェクトにするべきです。そうすれば、必要な場合はシェルによってテキスト表示に変換されます。しかし、任意のデータに対して、どのようにしてオブジェクトを作成したらよいのでしょうか。
先ほどの例を使って、空白のカスタム オブジェクトを作成して、それを変数の中に格納します。
$obj = New-Object PSObject
これで、新しい空のオブジェクトを使って作業を進めることができます。次に、データをプロパティの形にしてこのオブジェクトに追加します。単純に、オブジェクトを Add-Member コマンドレットにパイプするだけです。NoteProperty と呼ばれるものを追加し、プロパティに名前を付け (列のヘッダーをプロパティ名として使用することをお勧めします)、データをプロパティの値として挿入します。
$obj | Add-Member NotePropertyColumnA $data1
$obj | Add-Member NotePropertyColumnB $data2
$obj | Add-Member NotePropertyColumnC $data3
次に、オブジェクトをコンソールではなく、パイプラインに出力します。
Write-Output $obj
出力するテーブルの行ごとに、これらの手順を繰り返します。以下は、文字列を受け取り、元の文字列と共に大文字と小文字のバージョンを出力する短い関数です。
functionStringVersions {
param([string]$inputString)
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty Original($inputString)
  $obj | Add-Member NoteProperty Uppercase($inputString.ToUpper())
  $obj | Add-Member NoteProperty Lowercase($inputString.ToLower())
  Write-Output $obj
}
$strings = @("one","two","three")
foreach ($item in $strings) {
StringVersions $item
}
文字列変数の配列から始めて、これらを 1 つずつ関数に送ります。関数の出力がパイプラインに書き込まれます。
これより短いコードを書く方法もありますが、強調したい点を明確に表すためにこの手法を選びました。図 1 は、完全に書式設定されたテーブルの出力を示しています。シェルがテーブル内のオブジェクトを書式設定する方法を既に知っているからです。
図 1 テーブルに表示された Windows PowerShell の出力
図 1 テーブルに表示された Windows PowerShell の出力 (画像を拡大するには、ここをクリックします)
オブジェクト内のプロパティが 4 つ以下の場合、Windows PowerShell は自動的にテーブルを選択します。したがって、特に何もしなくても、見栄えの良いテーブルが完成しました。

しかし、この機能は、これだけではありません。
今月のコマンドレット : Get-Command
利用可能な Windows PowerShell コマンドレットの一覧を見るために、Get-Command または使いやすいエイリアス (gcm) を 1 度か 2 度は使用した経験があるかと思います。しかし、実際に gcm にどれほどの柔軟性があるかは、まだご存じないかもしれません。たとえば、Windows PowerShell がサービスに関してできることをすべて表示する場合は、gcm -noun service を実行します。また、Windows PowerShell のエクスポート オプションをすべて表示する場合は、gcm -verb export を実行します。PowerShell Community Extensions など、特定のスナップインによって追加されたコマンドレットを表示する場合は、gcm -pssnapin pscx を実行します (特定のスナップインのコマンドレットを表示するには、"pscx" の部分を該当するスナップイン名に置き換えます)。
ご覧のとおり、Get-Command は Windows PowerShell の検出における中心的存在です。これを使用することにより、マニュアルを手にしなくても、利用できる機能を調べることができます。また、機能を検出する際に Help * などのコマンドを使用するよりも gcm を使用する方が正しい結果を得られます。Help 関数は、用意されているヘルプ トピックを一覧表示するだけです。必要なコマンドレットが存在していても、それがヘルプと共に出荷されていない場合はヘルプの一覧に表示されません。

この手法のメリットはテーブルだけにとどまりません。オブジェクトを扱う場合、Windows PowerShell が実行できる機能の範囲は多岐に及びます。データを CSV ファイルに出力する場合は、Export-CSV を使用します。HTML 形式のテーブルに出力する場合は、オブジェクトを ConvertTo-HTML にパイプします。箇条書きの書式で出力する場合は、オブジェクトを Format-List にパイプします。オブジェクトを使用することにより、シェルが既に知っている方法をすべて利用することができます。次に、先ほどの例を書き換えたものを示します。
functionStringVersions {
  PROCESS {
   $obj = New-Object PSObject
   $obj | Add-Member NoteProperty Original($_)
   $obj | Add-Member NoteProperty Uppercase($_.ToUpper())
   $obj | Add-Member NoteProperty Lowercase($_.ToLower())
   Write-Output $obj
}
}
今回は、オブジェクトを扱う場合にお勧めする方法として、パイプラインの入力を受け取り、パイプラインに出力するように関数を変更しました。
この関数は、PROCESS スクリプト ブロック内にコードを含んでいます。つまり、関数はパイプラインの入力を受け取り、パイプされたオブジェクトごとに PROCESS スクリプト ブロックを 1 回実行します。
PROCESS スクリプト ブロック内では、特殊な $_ 変数によって、処理中の現在のパイプライン オブジェクトが参照されます。この実用的な結果として、単純に文字列の配列をパイプすることができるようになりました。
@("one","two","three") | StringVersions
関数の出力がパイプラインに書き込まれるため、テーブルが作成されます。パイプラインの最後に、シェルは書式設定のサブシステムを呼び出すことを知っており、パイプライン内のオブジェクトのプロパティの数が 5 よりも少ないため、テーブルを使用する決定が下されます (プロパティの数が 5 以上の場合、既定では、シェルは箇条書きを使用します)。
しかし、既定の動作を使用する必要はありません。他の形式に出力する場合は、これらのオブジェクトを別のコマンドレットにパイプすればよいのです。
@("one","two","three") | StringVersions | Format-List
@("one","two","three") | StringVersions | ConvertTo-HTML | Out-File "strings.html"
@("one","two","three") | StringVersions | Export-CSV "strings.csv"
@("one","two","three") | StringVersions | Select Uppercase,Lowercase -unique
図 2 は、2 番目の例で出力された HTML を Web ブラウザで表示したものです。出力データを単純なテキストではなく、オブジェクトとして表すだけで、さまざまな書式設定のレイアウト、HTML 変換、エクスポート オプション、並べ替え/フィルタ処理/グループ化の機能、その他シェルに組み込まれた数多くの豊富な機能を利用することができるようになります。
図 2 Windows PowerShell による HTML 形式でのデータ出力
図 2 Windows PowerShell による HTML 形式でのデータ出力 (画像を拡大するには、ここをクリックします)
これは非常に強力なツールです。実際、スクリプトを記述する場合は、オブジェクトをその出力として作成すべきであると勧めています。これにより、コードを 1 行すら追加することなく、可能な限り多様な方法で出力を作成することができます。

Don Jones は Windows 管理の自動化の専門家で、『Windows PowerShell: TFM』、『VBScript, WMI, and ADSI Unleashed』などの書籍を執筆しています。Don に対するお問い合わせについては、彼の Web サイト フォーラム (ScriptingAnswers.com) にアクセスしてください。


Hey, Scripting Guy! それほどコツコツ働かなくても報われる
The Microsoft Scripting Guys

この記事で使用しているコードのダウンロード: HeyScriptingGuy2008_06.exe (150KB)

何百年 もの間、コツコツ働けば必ず報われると信じられてきました。真の充足感は、1 日真面目に働くことによって得られるもので、真の幸せは、過程ではなく、終着点で得られるものだと。ほかにもありますが、言いたいことは、わかっていただけたと思います。(シンデレラみたいに) 不平不満を口にすることなくコツコツ働けば、いつか報われる日が来るのです。
注 : コツコツ働けば、今よりも幸せになるだけでなく、いつかその苦労が報われる日が来るというのは本当なのか、ですって。どうしてそんなことを私たちに聞くのですか。
言うまでもなく、シンデレラは幸運の持ち主でした。なにしろ、意地悪な継母とその連れ子である 2 人の異母姉妹と暮らしていたら、コツコツ働かなければならない機会はごまんとあります。けれども、彼女のような幸運の持ち主でない場合はどうしたらよいでしょうか。意地悪な継母と 2 人の異母姉妹と暮らしていない場合はどうしたらよいのでしょうか。また、報われることがない長時間に渡る厳しい労働にはどうやって耐えたらよいのでしょうか。それに、真の幸せは本当に見つかるのでしょうか。
あくせく働くことを決意している方に Scripting Guys がお勧めする作業は、図 1 に示すような、きれいに整ったテーブル形式でデータを出力するスクリプトを記述することです。
図 1 テーブル形式の出力
図 1 テーブル形式の出力 (画像を拡大するには、ここをクリックします)
繰り返しになりますが、シンデレラは強運の持ち主でした。彼女は家の中をすみずみまで掃除する必要がありました。また、その作業が終わった後に彼女が休める場所は、灰とすすにまみれた暖炉でした。けれども、このように過酷な労働に耐えたシンデレラでも、表形式でデータを表示するスクリプトを記述することには二の足を踏むでしょう。灰とすすの中で暮らすことと、表形式でデータを出力するスクリプトを記述することは、まったく別物です。
注 : ただし、暖炉の中に座ってスクリプトを記述しなければならないというのでなければ、これらの作業は同じようなものです。
シンデレラが、この作業に二の足を踏むのは、この作業が途方もなく難しいからです。VBScript を使用して表形式でデータを表示する唯一の方法の概要は下記のとおりです。
  • まず、各列の最大サイズを決めます。たとえば、サービスの表示名に 52 文字分の領域を使用する必要があるとします。
  • 次に、各データに含まれている文字数を算出します。たとえば、Adobe LM Service というサービスの表示名の文字数は 16 文字です。
  • 表示名が 52 文字の制限を超える場合、表示名用に割り当てた領域に収めるために、表示名の末尾から切り詰める必要がある文字数を特定します。表示名が 52 文字の制限を超えない場合は、表示名の長さを 52 文字にするために、文字列の末尾に追加する必要がある空白スペースの数を特定します。
  • 次のデータ セットについても同じ処理を繰り返します。また、それ以降のデータ セットについても同様です。
シンデレラの物語に詳しい方は、突然、妖精が現れて、ネズミをシステム管理者に変身させて、あなたの代わりにスクリプトを記述してくれる可能性があることはご存知ですよね (ネズミをシステム管理者に変身させることが、どれだけ簡単かということについてのコメントは差し控えさせていただきます)。けれども、そのような魔法はあてにすべきではなく、ここでは、自力で対応する必要があります。
ただし、朗報があります。このスクリプトを記述すると、世界中で最高の充足感を得ることができます。それは、このスクリプトを記述するということは、世界中で最もコツコツ働いている人になるからです。しかも、圧倒的にです。
そうですね。それほどコツコツ働かずに、ちょっとした充足感を得たいと思っている人もいらっしゃるでしょう。そのような方は「Scripting Guys は、ネズミをシステム管理者に変身させて、データを表形式で出力するようにネズミを誘導する方法を教えてくれる本当にありがたい存在だ」という風にお考えではないですか。大変申し訳ないのですが、そのような皆さんに残念なお知らせがあります。Scripting Guys は、ネズミをシステム管理者に変身させる方法については皆目見当も付きません (お役に立つかどうかわかりませんが、システム管理者をネズミに変身させることはできます)。スクリプトの代筆者を用意する方法もわかりませんし、表形式でデータを出力するスクリプトについては知る由もありません。
しかし、問題ありません。多くの皆さんが該当者になるとは思いますが、Windows® XP または Windows Server® 2003 を実行している場合は、あなたの代わりにスクリプトを記述するネズミは必要ありません (大変申し訳ありませんが、このスクリプトは Windows Vista® では動作しません)。Microsoft.CmdLib オブジェクトを使用すると、ご自身で、しかも最小限の労力でスクリプトを記述することができます。図 2 のサンプル スクリプトをご覧ください。
Figure 2 表形式でデータを出力するスクリプト
Dim arrResultsArray()
i = 0

Set objCmdLib = _
  CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = _
  WScript.Application

arrHeader = Array("Display Name", _
  "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" _
  & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery _
  ("Select * FROM Win32_Service")

For Each objService In colServices
  ReDim Preserve arrResultsArray(i)
  arrResultsArray(i) = _
  Array(objService.DisplayName, _
    objService.State,objService.StartMode)
  i = i + 1
Next
objCmdLib.ShowResults arrHeader, _
  arrResultsArray, arrMaxLength, _
  strFormat, blnPrintHeader, arrBlnHide
ご参考までに、Microsoft.CmdLib は、Windows XP と Windows Server 2003 に同梱されている COM オブジェクトで、さまざまな機能が用意されています。詳細については、コマンド プロンプトで「cmdlib.wsc /?」と入力して、画面上に表示されるスクリプト ファイルのコメントを参照してください。今日のスクリプトを記述する際に必要な Microsoft.CmdLib の機能は、表形式でデータを表示する機能だけです。
ここで当然ある疑問が浮かびます。「データを表形式で表示するには、どうしたらよいのか」という疑問です。では、その方法を解明してみましょう。ご覧のように、サンプル スクリプトでは、まず arrResultsArray という名前の動的な配列を定義しています。
Dim arrResultsArray()
一般的なスクリプトでは、データを取得すると、すぐに画面上にエコー バックします。しかし、Scripting Guys は、一般的なやり方を好みません。ですから、このスクリプトでは、データを取得しても、すぐにはエコー バックしません。代わりに、返された全データを配列に格納して、Microsoft.CmdLib オブジェクトを使用して、データの書式を設定して表示することにしました。
つまり、それが、このスクリプトの冒頭で動的な配列を作成した理由です (動的な配列とは、スクリプトの実行中にサイズを変更できる配列です)。配列を定義したら、i という名前のカウンタ変数の値を 0 に設定します。この変数は、配列の現在のサイズを追跡するのに使用します。
ご参考までに、i の値を 0 に設定した理由を説明しておきましょう。配列の最初の要素のインデックス番号は必ず 0 になります。ですから、配列に 1 つ目の要素を追加する際には、要素 1 ではなく要素 0 を追加することになります。
次に、Microsoft.CmdLib オブジェクトのインスタンスを初期化する必要があります。この処理を行うのが、次の 2 行のコードです。
Set objCmdLib = _
CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = WScript.Application
では、次の小さなコード ブロックに移りましょう。
arrHeader = Array("Display Name", "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)
ここでは、出力データを構成するためのいくつかのパラメータを設定しています。1 行目では、arrHeader という名前の配列に値を設定しています。ご想像のとおり、これらの値は出力する表の各列の見出しです。このサンプル スクリプトでは、コンピュータで実行中のサービスに関する情報を取得し、各サービスの DisplayName プロパティ、State プロパティ、および StartMode プロパティの値を表示します。
たいして驚くことではありませんが、配列には、Display Name、State、および Start Mode という列名を設定しています (列には単に A、B、C という名前や、Larry、Moe、Curly など、他の名前を設定することは可能です。列名をプロパティ名と同じにする必要はありませんからね)。
注 : シンデレラの物語には多くのバリエーションがあります。たとえば、異母姉妹の名前が異なったりします。ディズニー版のシンデレラの物語では、異母姉妹の名前は Drizzella と Anastasia です。これは偶然にも、編集者の名前とミドル ネームと同じです。
2 行目のコードでは、arrMaxLength という名前の別の配列に値を設定しています。この配列は、表の各列のサイズを保持するためのものです。このサンプル スクリプトの出力では、列 1 (サービスの表示名) に 52 文字分の領域を割り当て、サービスの状態と開始モードの列については、それぞれ 12 文字分の領域を割り当てます (Microsoft.CmdLib オブジェクトでは、列間に 1 つの空白文字が自動で挿入されます)。各列のサイズを 52 文字、12 文字、12 文字にするために、次のコードを使用しています。
arrMaxLength = Array(52, 12, 12)
3 行目では、データの出力形式を指定しています。ここではデータを表形式で表示する必要があります。そのため、(出力の種類を保持する) strFormat 変数に Table という値を代入しました。データを表形式ではなく、コンマ区切りの一覧として表示する必要がある場合は、次のように出力の種類を CSV と指定すれば問題ありません。
strFormat = "CSV"
このように指定すると、データは次のような状態で出力されます。
"Display Name","State","Start Mode"
"Adobe LM Service","Stopped","Manual"
"Adobe Active File Monitor V4","Stopped","Manual"
"Alerter","Stopped","Manual"
"Application Layer Gateway Service","Running","Manual"
"Apple Mobile Device","Running","Auto"
"Application Management","Stopped","Manual"
Microsoft.CmdLib オブジェクトによって、各項目間にコンマが挿入されるだけでなく、各値が二重引用符で囲まれています。これは、皆さんが想像していたよりも、すてきな機能だと思います。なにしろ、このような処理を手動で行う場合には、次のようなコードを使用する必要がありますから。
Wscript.Echo Chr(34) & objService.DisplayName & Chr(34) & "," & Chr(34) & objService.State & Chr(34) & "," & Chr(34) & objService.StartMode & Chr(34)
こんな複雑なコードは勘弁してほしいですよね。
何ですって。表形式と CSV 形式のどちらも好きではない、とおっしゃるのですか。そのような場合は、出力の種類を List と指定してみてください。そうすると、出力結果は次のようになります。
Display Name: Adobe LM Service
State:        Stopped
Start Mode:   Manual
Display Name: Adobe Active File Monitor V4
State:        Stopped
Start Mode:   Manual
それはさておき、本題に戻りましょう (私たちの話が脱線するのは、よくあることですよね)。出力形式を定義したら、blnPrintHeader という名前の変数の値を True に設定します。
blnPrintHeader = True
この blnPrintHeader 変数は、Microsoft.CmdLib オブジェクトに対して、列見出しを出力するように指示するのに使用します。列見出しを出力しない場合はどうするのか、ですって。問題ありません。その場合は、blnPrintHeader 変数の値を False に設定してください。
blnPrintHeader = False
最後に、次のコード行を使用します。
arrBlnHide = Array(False, False, False)
データを出力する段階では、列を表示または非表示にする Microsoft.CmdLib オブジェクトのオプションを使用できます。特定の列を非表示にするには (つまり、特定のプロパティのデータを出力しない場合は)、そのプロパティに対応する値を True に設定します。列を表示するには、False に設定します。
このサンプル スクリプトの出力では、DisplayName プロパティ、State プロパティ、および StartMode プロパティの値を、この順序で表示します。ですから、配列では、False, False, False という値を使用します。DisplayName プロパティの値を表示して、State プロパティの値を非表示にして、StartMode プロパティの値を表示する場合はどうするのか、ですって。その場合は、次のコード行を使用します。
arrBlnHide = Array(False, True, False)
列を表示する場合は False、非表示にする場合は True を設定することを覚えておいてください。
これで、データを出力する準備が整いました。まあ、実際にデータを保有していたら準備が整っているはずです (Scripting Guys は、これまでにデータを出力できないスクリプトを記述して、そのスクリプトのデバッグに多大なる時間を費やした結果、そもそもデータを取得していないことがわかったなんて失態を犯したことがあるのか、ですって。Scripting Guys がそんなことをするわけありません。一体どうして、そんなことを考えたりするのでしょうか)。
そのことを踏まえたうえでの、次のステップはというと、ローカル コンピュータの Windows Management Instrumentation (WMI) サービスにバインドして、ExecQuery メソッドを使用して、コンピュータにインストールされている全サービスに関する情報を取得することです。
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery ("Select * FROM Win32_Service")
ここでは WMI データ以外のデータも操作できるということをお伝えしておきましょう。お察しのとおり、Microsoft.CmdLib オブジェクトでは任意のデータを操作できます。WMI は、データ群を取得するのに便利な方法です。
サービスに関連するデータのコレクションを取得したら、そのコレクションに含まれている全サービスのデータを処理する For Each ループを設定します。ただし、ここでは、各サービスのプロパティ値をエコー バックする代わりに、次のコードを実行します。
ReDim Preserve arrResultsArray(i)
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
i = i + 1
このコード ブロックでは、どのような操作を行っているのか、ですって。1 行目では、配列のサイズを変更しています。ReDim Preserve コマンドを使用して、配列のサイズを変更するだけでなく、配列に格納されている既存のデータを保持しています (Preserve キーワードを指定しなくても、配列のサイズは変更できますが、その時点で配列に格納されているデータは消去されます)。
配列のサイズはどうしているのかというと、1 回目のループ処理では、配列のサイズは 0 に設定します。つまり、1 つの要素を含む配列を作成しています。配列のサイズを 0 にするという確証はどうやって得たかというと、カウンタ変数 i を使用していて、この変数の値が 0 だからです。
カウンタ変数 i を使用して配列のサイズを管理しているなら、配列のサイズが常に 0 になるのではないか、ですって。そうなるかもしれませんが、ループ処理を 1 回終えるたびに、i の値を 1 ずつ増やしているので、問題ありません。ご覧のように、この処理はコード ブロックの 3 行目で行っています。
ということで、注目する必要のあるコード行は次の 1 行だけになります。
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
この行では、単に必要なプロパティ (DisplayName、State、StartMode) の値を取得して、その値を arrResultsArray 配列に追加しているだけです。ここでは、プロパティの値を個別に追加するのではなく、配列の値として追加している点に注意してください。そうですね。これは少し一般的な処理ではないですね。arrResultsArray 配列の各要素は、別の配列になっています。ですが、これは Microsoft.CmdLib オブジェクトの仕様です。
そうですね。この動作が皆さんの心配の種になる可能性がありますね。「配列の配列ですか。配列の配列に格納されている各値には、一体全体どうやってアクセスするんだ」って思っていますね。落ち着いてください。簡単ですから。Microsoft.CmdLib オブジェクトが、皆さんの代わりに、この処理を実行します。
注 : ただし、Microsoft.CmdLib オブジェクトが皆さんの代わりに実行できるのは、配列の配列に格納されている値を取得してくることだけです。意地悪な継母の部屋を掃除したり、食器を洗ったり、意地悪な異母姉妹の洋服を作ったりする作業については、このオブジェクトの次期リリースで検討します。
実際のところ、ShowResults メソッドを呼び出して、スクリプトの前半で構成したすべての配列と変数を渡すだけで、きれいな表形式でデータを出力できます。
objCmdLib.ShowResults arrHeader, arrResultsArray, arrMaxLength, strFormat, blnPrintHeader, arrBlnHide
出力結果はというと、図 1 をお見せしたときに想定していた見事に書式設定された出力です。
悪くないですよね。それほどコツコツ働かずに、すてきな外観の出力が実現できました (次のスクリプトは、最初のスクリプトに少し変更を加えるだけでよいので、さらに簡単です)。
そうですね。確かに、スクリプトの出力を表形式で表示するためにシンデレラが日夜を問わず奴隷のように働いたときに得た充足感と同じ充足感は得られないでしょう。正直なところ、王子様と結婚することもないでしょう。それは、契約外のことですから。しかし、VBScript スクリプトで、このようにすてきな出力を実現できるなら、たいした代償ではないと思います。特に、近ごろの王子様というものが、どういった人たちであるかを考えれば、納得していただけるはずです。
でも、ひょっとしたら、あなた自身の王子様にめぐり会えるかもしれません。なにしろ、王族であっても、コンピュータにインストールされている全サービスに関する情報を取得する必要がありますからね。

Dr. Scripto のスクリプト パズル
パズルを解くスキルだけでなく、スクリプト作成スキルもテストする月に一度の課題です。

2008 年 6 月 : PowerShell の小道
以下の各パズルで、各文字を縦、横、斜めに一筆書きで、Windows PowerShell コマンドレットの名前を構成してください。各文字は一度しか使用できません。次に例を示します。
このパズルに含まれているコマンドレットの名前は New-Alias です。今度は、皆さんの番です。次の 3 つのパズルに挑戦してみてください。

ANSWER:
Dr. Scripto のスクリプト パズル
解答 : PowerShell の小道 (2008 年 6 月)

Read-Host

Set-AuthenticodeSignature

The Microsoft Scripting Guys は、マイクロソフトの仕事をしています、というよりもマイクロソフトにより雇われています。野球をプレイしたり監督したり観戦したり (または他のさまざまな活動を) しているのでない限り、彼らは TechNet スクリプト センターを運営しています。詳細については、www.scriptingguys.com を参照してください。


デスクトップ ファイル セキュリティと規制遵守
Wes Miller

IT プロフェッショナルは、相互に補完し合うべき目標が、逆に悪影響を与え合う状況に直面することがよくあります。セキュリティと規制遵守は、この状況をよく表している 2 つの組織目標ですが、一方を実現することによってもう一方が強化されることが理想です。ただし、残念ながら常にこの理想が叶うわけではありません。このコラムでは、
規制遵守がセキュリティとまったく等価値であると考えられているにもかかわらず、セキュリティを強化することが、必ずしも提示されたイニシアチブの要件を満たすことにならない理由、および規制を遵守することが、多くの場合、セキュリティを強化することにならない (少なくとも、必要なセキュリティを確保できない) 理由を大まかに説明します。

セキュリティはチェック ボックスではありません
SDL の関連情報
  • Michael Howard、Steve Lipner 共著『The Security Development Lifecycle』(Microsoft Press、2006 年)
  • セキュリティ開発ライフサイクルに関するブログ
  • マイクロソフトにおけるセキュリティ開発ライフサイクルの解説
  • セキュリティ デベロッパー センター
  • 信頼できるコンピューティングのセキュリティ開発ライフサイクル

一般的に、規制遵守とは、組織、業界、企業、または製品に対して外部から課せられる要件 (人、プロセス、インフラストラクチャ、テクノロジなど) を満たすことを意味します。また、業界内で推奨される標準 (支払いカード業界データ セキュリティ基準 (PCI-DSS) など) を満たすことを意味する場合もあります。これらのイニシアチブが、組織で既に取り組んでいる対策に、少なくともある程度対応していることが理想です。導入する標準の数が増えるにつれて、ビジネスを行うのであればその標準を無視するわけにはいかないことに気付き、最終的にはその中に飛び込み、目標の達成に全力を尽くすことになります。
通常、より厄介なのは、もう 1 つの種類の規制遵守です。これは、医療保険の相互運用性と説明責任に関する法律 (HIPAA) や米国企業改革法など、政府から提示されるイニシアチブのことを指します。これらのイニシアチブは、実装するかどうかや、そのタイミングを選択できる余地を与えてくれることはほとんどありません。
規制遵守の重要な特徴は、"トップダウン方式" の手法が関係してくることが多い点です。通常は、イニシアチブを定義する画一的な雛型が存在するので、使用している製品とプロセスと照らし合わせながら、配布されたこの奇妙な形の雛型にそれらを適合させる方法を見つけ出す必要があります。遵守イニシアチブの目的を認識しておくことも必要ですが、おそらくより重要なのは、遵守イニシアチブに従わない場合、またはその要件を満たすことができなかった場合に、どのような法律上または金銭上の悪影響 (考えられる場合) が発生するかを認識しておくことです。
多くの遵守イニシアチブの目的には同意できると思いますが、これらの実装は困難な場合が多く、要件を満たすことができない可能性があります。そして残念ながら、多くの遵守イニシアチブには強制力がありません (つまり、従わなくても、法律上または金銭上の直接的な悪影響は発生しません)。
治療を受ける患者として言わせていただきますが、私は HIPAA によってもたらされる利益について十分に説明できません。わかっているのは、病院に行くときにさらに多くの書類への記入を行わなければならないということのみです。さらに悪いことに、予期しない結果に直面することもあります。重要な医療情報を、ある医師や機関から受け取り、別の場所に持って行こうとしたことはあるでしょうか。許可書がなければ、どれだけ緊急に情報が必要な場合でも、その情報を入手することはできません。
問題は、一部の遵守イニシアチブが、色々な意味でチェック ボックス化していることです。つまり、遵守イニシアチブに従うという目的のためだけに、プロセスや製品が設計または変更されています。3 才になる私の子供によくする質問ですが、"本当にそれでいいのでしょうか"。
一方、セキュリティ イニシアチブには、その実装が正しく行われる場合、ボトムアップ形式の手法が使用されます。ソフトウェア製品を設計する場合でも、組織の新しいネットワークのアーキテクチャを設計する場合でも、重要なのは、周到に準備をするということです。たとえば、製品のアーキテクチャを設計する場合、最初の段階で通信手段、他言語への対応、バージョンなどを考慮することが推奨されていますが、アプリケーションに組み込む必要があるセキュリティ要素も、最初から設計に含める (そして、開発作業全体を通じて調査および改良していく) 必要があります。
他の人が設計したアプリケーションやアーキテクチャを使用する場合 (ほとんどの皆さんはこれに該当すると思いますが) は、このコラムでもよく言っていることですが、それらのセキュリティを徹底的に評価することが重要です。しくみがわからなければ、安全であるかどうかを理解することはできません。マイクロソフトのセキュリティ開発ライフサイクル (SDL) の詳細については、補足記事「SDL の関連情報」を参照してください。

全体像
セキュリティの強化とは、単に暗号化、アクセス制御リスト (ACL)、TLS、公開キー基盤 (PKI) などを実装することではないと昔教わったことを思い出します。真のセキュリティを提供するには、全体像を理解することが重要です。つまり、プロトコルの特定のバージョンが使用されなくなった、またはサポートすらされなくなった理由、新しく追加したコードによって介入者攻撃を阻止できる理由、製品の以前のバージョンの方が処理速度が速いにもかかわらず、次のバージョンで速度を犠牲にしてセキュリティを強化した理由などを理解する必要があります。また、インフラストラクチャのそれぞれの部分がどのように組み合わさっているかを理解することも重要です。
一方、規制遵守とは、使用しているテクノロジを評価し、構築したインフラストラクチャが一定の基準を満たすようにすることです。支払いカード業界データ セキュリティ基準 (PCI-DSS) や北米電気信頼度協議会 (NERC) などの一部のイニシアチブは、目的がはっきりしているため、これに従うことによって、正しくセキュリティを強化できると思います。ただし、最終的には、さまざまな種類の "遵守イニシアチブ" を選択し、特定のプロジェクトをそれらに適合させることになり、さらに利用できるリソースも限られているため、セキュリティ イニシアチブの要件を満たすことができなくなります。
セキュリティは、ソフトウェア開発において、長い間あまり重要視されてきませんでした。間違いなく、皆さんの多くはセキュリティを "後回し" にする組織に所属しています。現在、遵守イニシアチブが世間に浸透している理由は、"セキュリティは後回しにできる" という考え方が誤っており、これまでその考え方が功を奏したためしがないからです。

"とりあえず" という考え方
最近、私は転職しました。現在は、ここテキサス州オースティンにある規模の小さいベンチャー企業に勤めています。ここでは、Winternals で構築した Protection Manager 製品のテクノロジと若干似ている、安全なアプリケーションを登録する (ホワイトリストに追加する) テクノロジを構築しています。顧客と話していて非常に興味深いと思ったのは、顧客が現在使用しているテクノロジを安全であると考えていることです。より具体的に言うと、それらの顧客は、インフラストラクチャの構築に使用している一連のテクノロジを安全であると考えています。それらの大部分は安全で、セキュリティの脆弱性が原因で侵害されることはなさそうですが、少しうんざりするのは、システムが "とりあえず安全である" という評価をよく耳にすることです。
遵守イニシアチブにはおかしなところがあり、それは、従っても従わなくても問題が発生しないという点です。責任は皆さんにあります。たいてい、イニシアチブに従わないことの代償として挙げられるのは、罰金、罰則、または解雇です。多くの場合、本当に何かを変えるには、これだけでは不十分です。
あるイニシアチブに従うことが連邦政府によって義務付けられた場合、"とりあえず監査担当者を満足させよう" という考え方や、このイニシアチブを支える法律 (HIPAA など) の制定機関によって適切な資金が提供されないことを理由に、規制遵守に関するきちんとした体制を整えずに要件を満たそうとする組織が出てきます。これは、非常に少ない費用で、何の保証もないままイニシアチブに従おうとし、後になってあらゆる潜在的な影響に直面することを意味します。
多くの場合、セキュリティ イニシアチブに関しても同じ問題が発生しますが、少なくとも遵守イニシアチブに比べると考え方は明確です。開発者や実装者は、ある部分を仕様から除外すると製品が著しく脆弱になることを経営陣に前もって伝えておけば、少なくとも製品を出荷した後や展開が完了した後に、「だから言ったでしょう」と言うことができます。私の経験上、遵守イニシアチブの場合は、できるだけ少ない予算で、できるだけ早く要件を満たすことが求められます。目標は、そのイニシアチブの最低限の要件を満たすことのみであるため、要件を満たすことができても、その内容を継続的に意識することはできないと思います。

現在の状況を判断する
セキュリティと規制遵守の関連情報
  • セキュリティおよび準拠に関するソリューションのガイダンス
  • セキュリティ ガイダンス
  • 支払いカード業界データ セキュリティ基準の遵守に関する計画ガイド
  • 法令遵守とセキュリティ更新プログラム
  • コンプライアンスの達成
  • 人権に関する情報 - HIPAA
  • PCI セキュリティ スタンダード カウンシル
  • 北米電気信頼度協議会

理想としては、製品や組織のセキュリティを可能な限り強化してくださいと言いたいのですが、実際には、ほとんどの遵守イニシアチブが、不十分な設計や、多くの場合は自己満足による妥協の産物です。不幸なことに、私たちは "とりあえず" で事足りる世界に暮らしています。ただし、セキュリティの世界では、"とりあえず" が賢明であることはほとんどありません。世界中の IT プロフェッショナルは、遵守イニシアチブを喜んで受け入れ、精神と実装の両方において、そのイニシアチブに従おうとするかもしれませんが、組織に導入されているインフラストラクチャのセキュリティは、"できるだけ" 強化するのではなく、"必要とされる度合いまで" 強化する必要があります。つまり、単にイニシアチブの要件を満たすのではなく、真のセキュリティを手に入れることによって、規制を遵守する必要があるということです。
現在構築しているテクノロジが、商用ソフトウェアの一部であるか、大規模なシステムに統合する一連のテクノロジであるかどうかにかかわらず、そのしくみを 1 歩下がったところから見ることは重要です。システムの連結部分、それぞれの部分が連携するしくみ、およびシステムに対する大きな脅威について理解することの重要性は、いくら強調してもしすぎということはありません。
携わっている業界ごとに、さまざまな遵守イニシアチブが業務に影響を与える可能性があります。日常的に遭遇することもあれば、新しいプロジェクトやテクノロジの設計時のみ遭遇することもあります。また、法令遵守に関する評価または監査中に行う一部の作業でのみ遭遇する場合もあります。ただし、そのことは問題ではありません。遵守イニシアチブを無視した方がよいとは思いませんが、皆さんには現状を打破していただきたいと思っています。任務として課せられた遵守イニシアチブの要件を満たすための作業のみを行うのではなく、セキュリティに関するすべての点を評価することによって、使用しているテクノロジについて徹底的に理解し、法令遵守に関する評価を行う際に、そのテクノロジをモデル化する必要があります。

失うもの
最終的に遵守イニシアチブの要件を満たすことができなかった場合の罰則はあいまいです。要件を満たすことができなかった場合、そのイニシアチブが対象としている脅威の影響を実際に受ける危険性が残ることになります。この脅威はあいまいでわかりにくいかもしれませんが、確かに存在します。皆さん個人に影響が及ぶことはないかもしれませんが、現状に気を配りながら、常に最悪のシナリオも心に留めておいてください。
厳密なセキュリティの観点から同じ問題に目を向けると、この脅威は明らかになるはずです。そして、これは重要なことですが、脆弱性を未解決のままにした場合のコストをすばやく予測できるようにしておく必要があります。
このテーマについて、他の人たちとも話をしたことがありますが、多くの人は、遵守イニシアチブはかなり自由に解釈できるため、うやむやにされる場合があるという事実を力説していました。ただし、セキュリティ評価を実施すると、特定のセキュリティ対策を実装しなかった場合、その影響はうやむやにはならないことがわかります。そのセキュリティ対策を無視したことによって発生する直接的な脅威は、はっきりとわかります。脅威が明確にならない場合は、セキュリティ評価の実施者を再検討することをお勧めします。というのも、実装されているソリューションの中に存在する問題点を発見してくれる重要なチーム メンバを見逃している可能性があるからです。

無駄な努力
昨年、「データの損失を防ぐ方法」(technet.microsoft.com/magazine/cc162325) という、セキュリティに重点を置いたコラムを執筆しました。あれから 1 年が過ぎましたが、攻撃を受けるシステムの数、盗難にあった暗号化されていないラップトップの数、および流出した個人情報の量は増加しています。なんらかの進歩があったかどうかを判断するのは困難です。なぜ状況が変わらないのでしょうか。プロジェクトの進行はたびたび遅れています。これは、予算が非常に限られていること、リソースの負荷が高すぎること、および短い期間であまりに多くの機能を提供しようとすることが原因です。
残念なことに、このような環境では、必要最低限の作業が標準的な作業と見なされます。これではソリューションのセキュリティを確保することも、規制を遵守することもできませんが、プロジェクトのスケジュールやコストには致命的な影響を与えずに済みます。
個人的には、次のような信念を持っています。
  1. セキュリティを確保するつもりがない場合は、ソリューションを構築すべきではありません。
  2. 新しい機能を追加する場合は、必ず最初にセキュリティの設計を行う必要があります。
  3. 組織が設計プロセスにセキュリティを組み込むことに前向きでない場合は、企業または組織の全体的な方針に疑問を持つ必要があります。
組織が安全に保管する責任がある顧客やパートナーの個人情報はますます増えています。残念なことに、現在の世の中では、セキュリティがないがしろにされることがあまりに多く、従業員は安全性を感じられず、組織のセキュリティに対する姿勢を疑問視しています。
たいていは、実際にセキュリティ対策 (規制遵守ではありません) の欠如が原因で問題が発生したときに、"システムのセキュリティを強化する必要がある" ことを認識します。また、顧客、学生、患者、および従業員が、個人情報が漏洩したり金銭上の福利が侵害される可能性を懸念している場合は、"個人情報盗難保険" を標準的な説明手段として使用し、不安を取り除くことができます。
私たちは皆、過剰な量の作業を、ほとんどの場合少ない予算で、たいてい非常に短い期間内に行うよう要求されます。ただし、IT プロフェッショナルの責任として、なぜセキュリティが軽視されるのか、なぜ経営陣は、遵守イニシアチブが提示されたときや、セキュリティ障害が発生し (可能性はこちらの方が高いでしょう)、それによって法律上の脅威が実際に生じた、または生じる可能性があるとき (これによって組織の評価が下がり、窮地に陥ることもあります) でなければセキュリティについて考えないことが多いのかを問題として取り上げる必要があります。

挑戦してください
まずは、現状を打破することを試みてください。単に規制遵守のみを要求された場合、その作業を行うときに、他の人が考案したセキュリティの概念に従うことに時間を無駄に費やしているのではないと考えるようにします。システムのセキュリティを強化し、さらにその中で、遵守イニシアチブの要件を満たすことができるようにプロセスやインフラストラクチャを定義することを目標にしましょう。詳細については、補足記事「セキュリティと規制遵守の詳細情報」を参照してください。
要するに、規制遵守は、多くの場合、セキュリティに通じる道ではありませんが、セキュリティは、正しく実装し整備すれば、高い確率で規制遵守につながります。

Wes Miller は、テキサス州オースティンにある CoreTrace 社 (www.CoreTrace.com) のシニア テクニカル プロダクト マネージャです。以前は Winternals Software 社に勤務し、その後はマイクロソフトでプログラム マネージャとして働いていました。Wes の連絡先は、technet@getwired.com (英語のみ) です。


ビジネスにおける IT 環境リーダーになるための 10 のポイント
Michael Walsh and Eliza Walsh

おそらく、どの企業でも、環境への取り組みに関する話し合いが行われていると思います。IT は、そのような取り組みにおいて重要な役割を果たします。IT プロフェッショナルは、企業内と業界内で変化を推進し、思想リーダーとして活躍できる高い可能性を持っています。では、そのためには何から始めればよいでしょうか。この記事では、組織が環境と持続可能性に関する取り組みを推進するうえで、リーダーとして効果的な役割を果たすための 10 のポイントを示します。
問題を理解する
まず、環境の持続可能性とコンピューティングに関する知識を幅広く深めます。IT プロフェッショナルとしては、電源管理、ハードウェアの統合、環境廃棄物の管理など、コンピューティングが環境に与える影響を軽減する方法を十分に理解する必要があります。
また、環境リーダーとして、業務が環境に与える影響を軽減するために、IT 部門の枠を越えて、ソフトウェアとハードウェアがどれくらい役立つかを想定する必要があります。人事部門や営業部門の責任者、および弁護士と密接に協力して、企業が環境に及ぼす全体的な影響に対処するための方針を定義することになるかもしれません (出張規定から地球規模の二酸化炭素排出規制に至るまで、あらゆる方針が考えられます)。
企業内外の関係者は、環境リーダーが、環境、企業、および企業が属している業界に関する主要な専門知識を持っていることを想定します。そのため、環境の持続可能性と持続可能なコンピューティングだけでなく、企業の短期的および長期的な要件についても理解しておく必要があります。
新しい企業に勤めたり新しい役割を担う場合、おそらく迅速に行動を起こさなければならないというプレッシャー (実際に外部からかけられることもあれば、自覚することもあります) がかかるでしょう。特に、環境を意識した体制を構築したことがない (そして現在はそれを切望している) 企業ほど、この傾向が強くなります。
この迅速な行動を求める傾向には従わないようにしてください。その理由は、企業の信用だけでなく自身の信用も失う可能性があるためです。さしあたりは緊急の課題に焦点を合わせ、準備が整うか準備期間が終わったら、戦略的な構想について話し合うようにします。

企業を客観的に査定する
次に、企業または事業部門を環境と持続可能性の面から厳密に査定します。この作業には、主要関係者やその他の企業内外の協力者にも参加してもらう必要があります。
企業内外の人的ネットワークを構築し、関係者の図式を明確にする必要があります。これらの関係者は、環境の持続可能性に関する企業の取り組みの進捗を把握するうえで役立ちます。
与えられた責務にもよりますが、環境に関する規制、標準、および法律を企業がどれだけ遵守しているか (および今後どれだけ遵守するか) を確認することが必要になる場合があります。場合によっては、他企業の状況やアナリストの予想と比較した場合、企業が現在どのような状況にあるかを判断することも必要です。また、顧客、パートナー、行政機関、および影響力の大きい顧客団体が、企業に対して、および企業が行っている環境への取り組みに対して、どのような認識を持っているかを理解する必要があります。さらに、この取り組みに対して現在および今後課せられる、技術上、財務上、環境上の制約を確認することが必要になる場合もあります。
企業の規模や予算によっては、これ以外の追加調査も検討してみる価値はあります。内部調査、フォーカス グループ、第三者による調査などから、建設的な洞察が得られる可能性があります。これらの洞察によって、企業が過去に行った環境活動に対する従業員の満足度、競合他社と比較した場合に現在企業が置かれている位置、および考えられる市場機会について理解を深めることができます。ただし、ここで得られる可能性のある最も大きな価値は、第三者の調査によって、主要関係者の意見を確認したり、その意見に反論したりできることです。

目標とその達成時期を計画する
次に、企業の短期的および長期的な目標を把握します。まず、"短期" を 1 年、"長期" を 5 年とそれぞれ見積もり、その後これらの期間を要件に合わせて調整します。環境問題は決して短期間では解決できず、短期的な取り組みしか行わなかった場合、企業、株主、パートナー、および顧客に深刻な影響が及ぶことに注意する必要があります。
1 年と 5 年の両期間における企業の目標を決定するには、企業のビジネスが現在直面している、および今後直面することが予想される状況を判断する必要があります。これには、社風、企業のビジネスに関する短期的および長期的な目標、現在および今後の予算上の制約、地理的な拡張計画、業界の法律および規制環境の変化などが含まれます。
たとえば、データ センターは、戦術的な意思決定と戦略的な位置決めとの間に矛盾が生じることを示す良い例です。これまで、データ センターの設計における最大の考慮事項はスペースでしたが、ここ数年で、企業の成長を制限する要因が次第にスペースから電力へと代わり、電力が原因で運用コストが上昇するようになりました。電力が今後長期にわたって重要視されることに気付いたデータ センターの運用者は、エネルギー効率を向上させるための手段を講じ、それまで一般的にスペースを重視して決定が下されていたデータ センターの管理方針を根本から覆しました。消費電力を減らすための投資により、既存のパラダイムを維持する場合に比べて、短期的にかなりのコストが発生した例もありました。ただし、エネルギー価格が高騰したことによって、数年前に先を読んでデータ センターの管理方針を変更したデータ センターの運用者は、その先見性を評価され、企業自体も初期投資を上回る結果を得ることができました。

構想と戦略を決定する
次に、構想と戦略を決定します。言うまでもなく、まずは現在のビジネスの状況と今後の方向性を理解する必要があります。構想と戦略を決定する際は、これらを永続的なものと考えないようにします。企業が環境に配慮しなければならないという義務は永続的なものかもしれませんが、これは構想と戦略には当てはまりません。法規制、顧客の認識、ビジネス要件など、内的および外的な可変要素に合わせた抜本的な見直しが必要になるでしょう。企業による環境への取り組みが盛んに行われるようになった現在、IT に関する構想と戦略を、大企業の構想と戦略に同調させることは重要です。
構想を設定することは、ビジネスの方向性を示すことを意味します。注意深く言葉を選び、じっくりと考え、簡潔でわかりやすい構想を設定するようにし、あらゆる要件を盛り込もうとはしないでください。構想には、環境に関する企業の取り組みがすべて含まれている必要はありません。従業員とパートナーを正しい方向に導くために言及する必要がある問題のみを含めるようにしてください。多くの場合、構想の伝達には綱領 (または構想記述書) が使用されます。構想の伝達は、最初の半年以内に始めることが非常に重要です。
戦略を設定することによって、単に方向性が定義されるだけでなく、明確なビジネスの目標や目的が設定され、それらを達成するために行う投資の内容が大まかに決まります。戦略計画を立てる際は、既存のモデルを使用できます。環境と持続可能性に関する計画のモデルとして、2 つの最適なモデルが提供されています。これらは、SWOT モデル (強み (Strength)、弱み (Weakness)、機会 (Opportunity)、脅威 (Threat)) と PESTLE モデル (政治 (Political)、経済 (Economic)、社会 (Social)、技術 (Technological)、法律 (Legal)、環境 (Environmental)) です。これらを活用し、戦略計画などの文書によって戦略を定義できます。
記述書を公表する前に、構想と戦略に賛成していると思われる関係者と、反対していると思われる関係者の両方から広く意見を求めることによって、高い確率で成功を収めることができます。最終的な計画で反対派からの意見に対処する担当者にとって、このことは特に重要です。

ビジネス上の重要課題を浸透させる
重要課題の説明は、構想と戦略を公表した後ではなく、リーダーの役割を担ったその日から始める必要があります。ただし、公表後は、企業の内外を問わず、より広い範囲の協力者に説明を行う必要があります。まず、従業員、アナリスト、メディア、パートナー、顧客、顧客団体など、影響力の大きいグループに、自身または代理人から構想を伝達する必要があります。構想と戦略を信頼してもらうために、これらの協力者の関心と士気を高め、また、その戦略が企業と協力者にとって最良の結果をもたらすことを理解してもらうために、説得力のある説明を行う必要があります。
次は、戦略を構成するそれぞれの要素に焦点を移します。また、すべての段階を通じて、最新の情報を定期的に協力者に提供する必要があります。これには、成功までの重要なマイルストーンを示すこと、戦略の変更点を伝達すること、および企業と業界全体が抱える課題を率直に説明することが重要です。
協力者ごとに異なる関心やニーズが提示されることに注意してください。各協力者の特定のニーズや関心にも応える必要がありますが、基になる構想と戦略の一貫性は維持する必要があります。これによって、より効率的にさまざまな協力者から賛同を得ることができます。
異なる協力者のニーズに応えることを目的として、相反する "ビジネス要件" を伝達することがないようにしてください。リーダーがこのような行動を取っては、取り組みに対する信用は得られません。少なくとも、変化を推進する際に、効果的な協力が得られなくなる可能性があります。最悪の場合には、企業全体の信用が失われることも考えられます。図 1 は、メッセージを効果的に伝達するための 7 つのポイントを示しています。
図 1 メッセージを伝達するための 7 つのポイント
図 1 メッセージを伝達するための 7 つのポイント (画像を拡大するには、ここをクリックします)

メッセージの伝達を管理する
構想と戦略を説明する際は、内部と外部のどちらに対して説明を行う場合でも、メッセージの専門性と一貫性を考慮してください。環境と持続可能性は、製品の開発、サービス、売り上げ、およびマーケティングに関係しているだけでなく、企業の社会的責任にも関係しています。組織の職務として環境リーダーを任命された場合でも (環境の持続可能性に関する市民の取り組みを直接管理することはできなくても)、市民のリーダーとして規範を示すつもりで行動する必要があります。
外部協力者の環境問題に対する情熱と、環境に関連するビジネス手法への理解度を過小評価しないようにしてください。さらに重要なことに、協力者は、メッセージに一貫性がない場合や、その実現に対する確信が大きすぎる場合や小さすぎる場合、きちんとそのことを認識する能力があることを覚えておいてください。これらのことに注意しなければ、企業に "環境保護を謳うだけの団体" というレッテルが貼られる可能性があります。
したがって、伝達戦略には、公に説明を開始する前に内部の専門家に意見を求めることができる再検討プロセスを組み込む必要があります。また、メッセージ伝達を構成する主な要素の骨組みを提供する必要があります。たとえば、環境に関する企業の取り組みをまとめた報告書、メッセージ伝達の枠組み、承認されている広報担当者の一覧、主張の裏付けなどです。伝達戦略は、明確な骨組みと一貫性を提供するうえで重要な役割を果たすので、構想と戦略を決定した直後に、この伝達戦略を決定する必要があります。また、メッセージ伝達の主要担当者には、各自の行動に対する説明責任を課すとよいでしょう。

評価指標を使用した管理を行う
構想と戦略に関連する説明責任を管理することは重要です。運用、製品開発、または営業のいずれの分野でも、目標と目的の達成に影響する要因を定義する必要があります。これらの要因を簡潔な一覧にまとめ、全体的な戦略計画に関連付ける必要があります。その後、これらの要因を質的および量的な基準として設定し、管理用の評価指標として今後の分析に使用できるようにします。これらの評価指標は、状況に合わせて随時調整していく必要があります。
これらの管理用の評価指標を使用した報告に関する説明責任を明確に定義し、すべての主要関係者による定例会議を実施する必要があります。これによって関係者は、管理用の評価指標が戦略計画の達成度に与える影響について議論できます。これは、評価指標を定義済みの要因に関連付け、それらの要因を戦略計画の各要素に関連付けることで可能になります。
残念ながら、多くの組織はこのような管理用の評価指標をサポートできる評価ツールを所有していないと思います。ただし、これらのツールは、環境と持続可能性に関する取り組みの厳密な分析と報告を行うために必要とされる質的および量的なデータを提供するうえで不可欠です。したがって、特殊な評価ツールの開発を行う必要があります。これを行うには、ビジネス プロセスを再設計するか、共同作業および評価テクノロジを展開するか、カスタマイズされた内部ツールを開発します。
こうした評価ツールへの企業の投資に関して上位の責任者から支援が得られない場合、費用対効果を十分に考慮して、余分な人員を割いてまで適切な評価ツールの開発を優先するかどうかを決定する必要があります。

環境に関する取り組みの影響を分析および報告する
質的および量的なデータを収集することで、詳細な分析が可能になります。この分析は、リーダーとして、どれくらい計画が成功しているか、およびこの取り組みによって企業や事業部門にどのような影響が及ぼされるかを理解するうえで非常に重要です。
環境に関する報告という点で、規制、標準、法律、および企業の意識が変化したことによって、環境への取り組みに関する詳細情報を公表しなければならないという企業へのプレッシャーが増大しました。管理、評価、分析をサポートするためのツールとプロセスを使用することによって、義務付けられた年次報告、必要な書類の提出、持続可能性に関する企業の自主的な報告などに必要な情報を容易に収集できます。したがって、報告に関する現在および今後の要件を理解することが重要です。これにより、統合された管理、評価、分析、および報告基盤への投資を行い、ビジネス要件に応じてこれを強化していくことができます。
分析および報告テクノロジは、企業が思想リーダーとなるうえで非常に重要です。ここで、ソフトウェアが重要な役割を果たします。これは特に、環境に関する取り組みの管理、プロセスの設計、データ収集、データ操作、遠隔地での測定、共同作業、視覚化、およびプレゼンテーションに使用されるソフトウェアを指します。
場合によっては、市販のソフトウェアを、この環境に関する取り組みに合わせてカスタマイズする必要があります。このため、統合された管理、評価、分析、および報告基盤を構築するために、テクノロジへの大きな投資が必要になる可能性があります。

思想リーダーになる
思想リーダーは、すべての環境リーダーが目指すべき地位です。さまざまな種類の思想リーダーが存在しますが (図 2 参照)、すべてに共通するのは、その専門家としての力量が、肩書きではなく、行動の実績、および一貫性と公開性を重視した変化の推進によって決まるという点です。
図 2 思想リーダーの種類
図 2 思想リーダーの種類 (画像を拡大するには、ここをクリックします)
環境の持続可能性を向上させるうえで、思想リーダーによる変化の推進は重要な役割を果たします。思想リーダーは、政府組織、非政府組織、業界団体、および消費者擁護団体に人的ネットワークを拡大し、関係者を相互に結び付けることによって、緊密な連携を必要とする問題に対処します。また、国際社会が懸念している多くの新たな環境問題について理解し、それらの問題について、すべての協力者に注意を促します。
さらに、思想リーダーは、まだ業界全体が注目していない重要な問題の解決策を構想します。こうした解決策の構想には、競合他社を含む他の関係者への働きかけや、これらの関係者との共同作業が必要になることもあります。また、こうした解決策を提示することによって、まだその需要に対応できていない市場に、企業として挑むことになるかもしれませんが、その結果として、業界全体に変化をもたらすことができます。

最新の情報を提供する
"環境リーダー" は新たに生まれた専門分野であり、必要な知識は日々変化しています。継続的に信頼を得るには、他の環境リーダーが発展させている、科学、政治、法律、経済、技術、ビジネスなどのさまざまな分野の考え方を学術的に理解する必要があります。また、必ずしもその時点で優位な立場にある意見に従うのではなく、環境の持続可能性とコンピューティングに関する専門家としての理解に基づいて、独自の考え方を発展させる必要があります。業界の環境リーダー (または思想リーダーであると主張する人々や団体) の増加を考慮すると、この一貫性が差を付ける大きな要因になります。
能力の高いリーダーは、目的のトピックに関する特定の知識を持つ部下に責務を委任する際や、企業内の環境施策に関するより上位の責任者に決定を委任する際に、その委任した作業が成功する可能性を最大限に高めることができます。代表者と定期的に会議を行ったり、報告を提出したりすることによって、環境の持続可能性に関する企業の取り組みを包括的かつ継続的に理解できますが、最も重要なことは、企業を代表して報告を行う必要がある状況を認識することです。それには、自身の主な責務を明確に理解する必要があります。またそれこそが、組織内外の協力者が期待を寄せる、環境に関する企業の信念を支えるために、環境リーダーが果たす必要がある真の責任です。

Michael Walsh は、マイクロソフトで環境関連製品のシニア プロダクト マネージャを務めています。
Eliza Walsh は、コミュニケーション戦略コンサルタントとして活動しています。以前は、マイクロソフトの中国法人でコミュニケーション スペシャリストを務めていました。


フィールド ノート 分割画面を共有する
Kentaro Toyama

可能な限り多くの人が PC にアクセスできるようにしたことは、Microsoft Research India が掲げている目標で、賞賛に値するものです。この目標は、複数のマウスを使用して、多くのユーザーが 1 台の PC を操作することを可能にするプログラムである MultiPoint で成功を収めています (このプログラムについては、2008 年 5 月号の TechNet Magazine で説明しています)。
分割画面は、コンピュータを同時に共有するために Microsoft Research India が考案した MultiPoint とは別のテクノロジです。このプログラムは 1 台の PC に 2 つのキーボードと 2 つのマウスを設定し、その後モニタを真ん中で分割するようにターミナル サービスを変更します。2 人のユーザーは、1 台のモニタを共有し、それぞれが分割画面の半分を使用して、別々の OS のインスタンスと好きなソフトウェアを実行できます (research.microsoft.com/users/udaip/splitscreen.htm)。たとえば、1 人のユーザーがスプレッドシートで作業しているときに、もう 1 人のユーザーは文書の処理を行うことができます。
分割画面を実現するために、Windows Server® 2003 上で実行中のターミナル サーバーの 3 つのインスタンスを使用しています (現在 Windows Server 2008 へのアップグレードに対応中です)。1 つ目のインスタンスはコンテナとして使用し、すべてのマウスとキーボードのイベントをキャプチャして再分散します。この層では、すべてのマウスとキーボードのイベントがデバイス ID と併せてキャプチャされるという MultiPoint で使用したものと同じ方法を使用します (Windows® では USB デバイスの接続時に自動的に一意の ID が割り当てられます。これらはハードウェア デバイスに一意なものではありませんが、操作中のインスタンスでは一意です。これは、2 回のマウス クリック操作が 1 つのマウスで行われたものなのか、複数のマウスで行われたものなのかを認識する際に必要な機能です)。コンテナでは、マウス カーソルを描画します。
コンテナ内で、別の 2 つのターミナル サーバーのインスタンスを開きます。これらのインスタンスでは、それぞれが 1 つの画面に関連するイベントのみを受け取ります。既定のモードでは、たとえば ID が x のマウスのすべてのイベントは分割画面の左側に対応し、ID が y のマウスのイベントは分割画面の右側に対応します。
分割画面では、ターミナル サービスを使用して PC のモニタを真ん中で分割します
分割画面では、ターミナル サービスを使用して PC のモニタを真ん中で分割します (画像を拡大するには、ここをクリックします)
どのイベントがどちらの画面に対応するのかを完全に制御し、より高度な機能を実現するために、ターミナル サーバーのコンテナ インスタンスを使用することは重要です。たとえば、右側の画面に対応しているカーソルを左側の画面に移動して、単純にポイントしたり (チュートリアルを行うためなど)、または左側の画面で操作をすることも可能です。
このような場合は、右側の画面のマウス イベントの一部が左側の画面でも受け取られます。Windows の仮想化テクノロジを使用して同様の機能を実現することも検討しました。これは可能なことですが、リソース消費量が多くなることがわかりました。
調査員は、画面の半分だけしか使えないことに、不満が出るのではないかということを心配していました。インドのバンガロールで、都市部の低所得者層の若者を対象に、コンピュータの基礎を教えている Hope Foundation と協力して調査を実施しました。学生たちは、少なくとも限られた量の IT トレーニング タスクにおいては、分割画面を使用した場合も、1 台の PC を使用した場合と同じように学んだようです。また人間工学の問題についても調査しましたが、14 インチ画面のモニタでも問題は発生しませんでした。最も重要なことは、IT トレーニング センターが、同じ台数の PC で 2 倍の数の学生を受け入れられると喜んだことです。
Microsoft Research India は、分割画面を商品化する価値があるものかどうかについて、ターミナル サービスと他のマイクロソフト グループと話し合いを進めています。分割画面の導入を検討されている場合は、どのようなシナリオで使用するかについて、splitscr@microsoft.com (英語のみ) まで電子メールをお送りください。

Kentaro Toyama は、Microsoft Research India (research.microsoft.com/india) の取締役補佐を務めています。また、世界の経済的に貧しい国々のためにテクノロジを開発している Technology for Emerging Markets グループ (research.microsoft.com/research/tem) の主要調査員でもあります。


Windows 秘話 最も悪名高い 2 つの PC 機種
Raymond Chen

2007 年 3 月 に『PC World』で最も悪名高い PC 機種トップ 10 が発表されたとき、私が実際に職場で使用したことがあったトップ 2 の機種が目にとまりました。そうですね、「使用したことがある」というのは言い過ぎですね。おそらく、これらの PC を「見たことがある」と言うべきでしょう。というのも、これらの PC は、その生産的な一生の大半をあるマイクロソフト社員のオフィスで過ごしたからです。
Mattel 社製 Barbie PC が『PC World』に掲載されたリストの第 2 位にランクされていました。この PC は、味気ない色の安価なコンピュータに大幅な進歩をもたらしました。この PC は、本体、モニタ、スピーカをピンクのシールで飾り立てることができるという味気ない色の安価なコンピュータでした (この説明で、"進歩" というのが、どういうことかおわかりいただけたと思います)。また、この PC には Barbie がテーマのソフトウェアがプリインストールされていました。
私たちは、テスト用 PC として、この PC を 1 台購入しました。この PC を使用することになった不憫なテスターは、同封されたすべてのシールと飾りを使用して PC を装飾するユーモアのセンスを持ち合わせていたので、仕様どおりにコンピュータを設定しました。この PC は通路からはっきりと見えるテーブルに設置され、そこを通りかかって鮮やかなピンク色のシールで飾り立てられたコンピュータが目にとまった人は、だれでも自由に操作することができました。
Barbie PC は、しばらく楽しませる物として役立ちました。この PC で問題が発生して、開発者がこの PC を修理するためにオフィスに来る必要があって、修理が必要なコンピュータが Barbie PC であることに気付くと、必ず PC をしげしげと見つめたり、「かっこいい」という叫び声を上げたりすると言っても過言ではありませんでした。また、ある夏、大学生のインターンが、騙されて Barbie PC に Windows Server® Datacenter Edition をインストールしたと聞きました。
最高の栄誉 (厳密には最低の栄誉ですが) は Packard 社製の Bell PC に与えられました。懐かしいですね。このコンピュータの設計がどれだけ優れていたかを示す一例は、購入時に既にすべての拡張スロットが使用されていることです。おそらく、同社は「このコンピュータは完璧なのでアップグレードの必要はない」と考えたのでしょう。
Windows® 95 プロジェクトが進行していたとき、ある幹部社員が自宅で使用する PC として、この PC を購入し、実稼動環境テストの一環として定期的に Windows 95 の最新ビルドをインストールしていました。ご想像のとおり、いろいろな問題が発生し、この PC は修理のために頻繁にオフィスに持ち込まれる必要がありました。
Windows 95 プロジェクトの開発マネージャは聡明な人で、果敢にも問題解決に直接的な方法を取りました。たとえば、Windows 95 でさまざまなアプリケーションとの互換性を確保するために、小型トラックを運転して地元のコンピュータ店へ行き、その店で販売されているすべての PC プログラムを 1 つずつ購入しました。そして、彼はカフェテリアのテーブルの上に購入したソフトウェアを並べ、Windows 95 製品チームのメンバを召集して、2 つのソフトウェアを選ぶように指示しました。選んだソフトウェアを Windows 95 にインストールして実行し、正しく動作しないものについては、その問題の大小にかかわらずバグとして報告するという使命を課しました。この作業と引き換えに、選んだソフトウェアをもらうことができました。召集されたメンバはテーブルに並んでいるソフトウェアから掘り出し物を探して、他のメンバに「何を選んだの」と興奮しながら聞いていて、カフェテリアは、まるでノミの市のようでした。
幹部社員が自宅で使用しているコンピュータを修理のために頻繁に持ち込まなければならないという状況に気まずい思いをした Windows 95 プロジェクトの開発マネージャは、再び直接的な問題の解決策をとりました。今度は、地元のコンピュータ店で、幹部社員が使用しているのと同じ Packard 社製の Bell PC を購入したのです。
このコンピュータが 2 台あったということだけでも十分不幸な事実なのに、さらに悪いことは、この新しく購入したコンピュータに Windows 95 のすべての新しいビルドをインストールし、問題が発生した場合にはデバッグするという使命が私に課されたことです。このようにして、幹部社員が自宅のコンピュータに最新のビルドをインストールしたときには問題が発生しないようにしました。
これまでの話を理解していて、全体像を把握されている場合は、この問題解決方法の欠点にお気付きでしょう。Packard 社製の Bell PC には空いている拡張スロットがないため、ネットワーク アダプタ カードを取り付ける場所がないのです。そのため、ネットワーク接続を実現するには、他の遠回りした手段を取らなくてはなりませんでした。あのコンピュータには本当にうんざりしました。

Raymond Chen は自分の Web サイト「The Old New Thing」および同じタイトルの書籍で、Windows の歴史と Win32 プログラミングについて扱っています。鏡の中に映って見えるものは、見かけより近くにあります。