• [アーティクル]

Windows 7

Windows 7 のお勧めセキュリティ機能

Steve Riley

 

概要:

  • DirectAccess による社内ネットワークへのアクセスが簡略化
  • 新しい BitLocker 機能を使用してリムーバブル ディスクを暗号化する
  • AppLocker を使用してアプリケーションへのアクセスを管理する
  • DNSSEC を使用して DNS の侵害とスプーフィングから保護する

目次

DirectAccess
BitLocker と BitLocker To Go
AppLocker
DNSSEC
その他の強化機能
最強の Windows

この記事の最終校をしていたときに、私たちの多くが待ち望んでいた Windows 7 が遂にリリースされました。私はベータ版とリリース候補版を長期に渡って運用システムとして使用しましたが、Windows 7 に施された変更点と機能強化には好感を持っています。今月の記事では、私が気に入っているセキュリティ機能をいくつかご紹介します。

DirectAccess

一般的な IT プロフェッショナルの仕事は、退勤時に終わるわけではありません。多くの企業では、なぜ社員に、デスクトップ コンピューターではなく、ラップトップ コンピューターを支給していると思いますか。それは、ラップトップを支給すると、社員が勤務時間外に仕事をするようになるからです。そのため、企業は、より高価なハードウェアに投資しても、その投資を回収できます。数台の VPN サーバーを設置して、社内ネットワークにアクセスする手順書を公開すれば、社員の生産性はさらに上がります。

とにかく、理論的には、そのようになります。VPN を使用すると、社内ネットワークにアクセスするには、追加の手順が必要になり、この手順は、非常に複雑になることもあります。また、簡単に紛失してしまうハードウェア トークンを持ち歩く必要があります。古臭いログオン スクリプトは、恐ろしいほど処理に時間がかかります。インターネット トラフィックは、社内ネットワークの影響を受けて、応答が遅くなります。前回 VPN を使用してから時間が経っている場合は、数 MB もの更新プログラムをコンピューターにインストールしなければならないこともあります。たとえば、経費報告書を提出しなければならないなど、社内ネットワークへのアクセスが必要な作業が 1 つしかなく、それが些細な作業であれば、VPN に接続するのを見合わせるでしょう。ですが、VPN 接続を確立するための追加手順をなくして、自宅や空港のラウンジで、社内にいるときと同じように社内ネットワークに接続できる方法があれば便利です。

Windows 7 の DirectAccess 機能を Windows Server 2008 R2 と組み合わせて使用すると、このシナリオを実現できます。ユーザーの観点では、社内ネットワークとインターネットの違いはありません。たとえは、社内で作業中に経費報告書を提出するには、http://expenses にアクセスします。社内ネットワークで DirectAccess が有効になっていると、インターネット接続を確立できる場所であれば、どこにいても同じ手順を使用して経費報告書を提出できます。必要な操作は、ブラウザーのアドレス バーに「http://expenses」と入力するだけです。追加のログオン手順やトレーニングは必要なく、言うことを聞かない VPN クライアント ソフトウェアのトラブルシューティングを行うためにヘルプ デスクに問い合わせる必要もありません。DirectAccess を使用すると、コンピューターを社内ネットワークとインターネットに同時に接続できます。そのため、ユーザーとアプリケーションの間で競合が発生することなく、簡単にデータにアクセスできます。

このシナリオを実現しているのが、IPsec および IPv6 という 2 つの通信プロトコルです。IPsec のカプセル化セキュリティ ペイロード (ESP) トランスポート モードのセキュリティ アソシエーション ("IPsec トンネル" という不適切な表現が使用されていますが、トンネルではありません) では、クライアントとサーバー間の通信を認証および暗号化します。双方向の認証により、man-in-the-middle 攻撃を軽減できます。また、クライアントとサーバーの両方で信頼されている証明機関で発行された X.509 証明書を使用して、クライアントとサーバーは相互に認証します。Advanced Encryption Standard (AES） 暗号化では、機密性が確保されるので、通信中にデータが傍受されても、そのデータは意味を成さないので問題ありません。

従来の VPN でも IPsec を使用していました。これは IPv6 の付属物のようなもので、DirectAccess を新しく興味深いものにするのに一役買っています。VPN を廃止するには、ネットワーク アドレス変換機とアドレス範囲の重複が多い IPv4 よりも優れたエンド ツー エンドの接続性を提供する必要があります。IPv6 では、各クライアントでグローバルに一意でルーティング可能なアドレスを構成し、社内ネットワークのトラフィックを通常のインターネット トラフィックから分離します。DirectAccess では IPｖ6 が必要なので、社内ネットワークでは IPv6 がサポートされている必要があります。これは皆さんが思うほど難しい作業ではありません。多くのサーバーは、既に IPv6 で実行するように構成されているか、そのように構成することが可能です。また、5 年以内に製造されたネットワーク機器では IPv6 がサポートされています。社内ネットワークの境界では、ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) や NAT-PT (Network Address Translation/Protocol Translation) などのプロトコルを切り替えるテクノロジが役立ちます。

DirectAccess を使用するように構成されたクライアントは、常に社内ネットワークに接続していますが、接続にはネイティブ IPv6 は使用していません。というのも、クライアントは IPv4 NAT の内側に存在し、インターネット自体が IPv4 を使用していることが多いからです。Windows 7 では、6to4 と Teredo をサポートしています (これらは、IPv6 を IPv4 にカプセル化する移行テクノロジです)。めったにないことですが、このどちらのプロトコルも機能しない場合、DirectAccess では、IP-HTTPS にフォールバックします。IP-HTTPS は、IPv4 ベースのセキュリティで保護された HTTPS セッションに IPv6 をカプセル化する新しいプロトコルです (HTTP を究極のユニバーサルなバイパス プロトコルに変換する枠組みは地に落ちました)。

DirectAccess 経由で機能するために、アプリケーション側で必要な変更や特別な処置はありません。グループ ポリシーによって、クライアントに名前解決ポリシー テーブル (NRPT) が割り当てられます。このテーブルには、社内ネットワークの DNS サフィックスと名前空間を解決する DNS サーバーの IPv6 アドレスという 2 ビットの情報が格納されています (図 1 参照)。DNS サフィックスが inside.example.com で、DNS サーバーの IPv6 アドレスが FEDC:BA98:7654:3210::1 だとします。http://expenses にアクセスすると、コンピューターのリゾルバーによって DNS サフィックスが追加され、expenses.inside.example.com の名前解決が試行されます。これは NRPT に格納されている DNS サフィックスのエントリと一致するので、リゾルバーによって要求が FEDC:BA98:7654:3210::1 に送信され、DNS サーバーからは expenses サーバーの IPv6 アドレスが返されます。DirectAccses では、必要な手順 (ネイティブ IPv6、移行、IP-HTTPS) を実行して、サーバーへの接続を確立します。コンピューターがドメインに参加していて、サーバーで認証が必要な場合は、ログオンに使用したドメインの資格情報で認証が行われます (認証のダイアログ ボックスは表示されません)。別のブラウザー ウィンドウで、パブリック Web サイトを閲覧しているとします。このサイトの DNS サフィックスは、コンピューターの NRPT には存在しないので、リゾルバーでは、(ネットワーク インターフェイスで構成されている DNS サーバーを使用して) 通常の IPv4 によるルックアップを実行し、DirectAccess を使用せずにサイトに接続します。

figure1.gif

図 1 DirectAccess の名前解決ポリシーを設定する (クリックすると拡大画像が表示されます)

社内ネットワークへの常時接続による影響について少し考えてみましょう。ユーザーにとっては、常用依存性があり、難なく経費報告書を提出できるようになります。ですが、この記事の読者である管理者やセキュリティ担当者にとっては状況が異なります。クライアント コンピューターが、どこからでも社内ネットワークに常時アクセスできるというのは、どのような作業が必要になるのでしょうか。次に、その例をいくつか紹介します。

  • グループ ポリシーによるメンテナンスの構成
  • Windows Server Update Services (WSUS) または System Center Configuration Manager (SCCM) による更新プログラムの常時配信
  • NAP による正常性チェックと修正
  • Windows ファイアウォールと Forefront Client Security などの一元管理されたマルウェア対策プログラムによる保護

この例を見る限りでは、社内で行っている作業と変わりありませんね。そのとおりです。DirectAccess では、社内ネットワークをインターネット全域に拡張しながら、コンピューターを適切に管理してセキュリティを確保することができます。これほど興味深いネットワーク テクノロジに出会ったのは久しぶりなので、これは Windows 7 にアップグレードする起爆剤となるでしょう。

BitLocker と BitLocker To Go

執筆者としてあるまじき行為ですが、少しの間、皆さんに私の話の腰を折るようにお願いしたいと思います。Privacy Rights Clearinghouse (privacyrights.org/ar/ChronDataBreaches.htm、英語) でデータ漏洩の年表を見てみてください。このサイトでは 2005 年 1 月からデータ漏えいに関する情報を収集しています。この記事を執筆している時点までに、なんと 2 億 6,300 万件ものデータ漏えいが発生しています。Ponemon Institute LLC と PGP Corporation が行った調査 "The Fourth Annual U.S. Cost of Data Breach Study: Benchmark Study of Companies" (企業の基準研究: 第 4 回 - 米国におけるデータ漏えいにかかるコスト、英語) によると、1 件のデータ漏えいに付き、データの復元には平均 202 ドルかかると報告されています。ちょっとした計算をしてみましょう。

263,000,000 件のデータ レコード × $202/データ レコード

$53,000,000,000

企業では、驚くことに 5 年半で 530 億ドルもの損失が発生していることになります。多くの企業にとって、不適切な場所に置いたり、盗難に遭ったりしたラップトップ コンピューターは、最もコストがかかる損害の 1 つです。新たに機器を購入するコストは、それほどかかりません。コストがかかるのは、データの回復や再生、罰金、評判への悪影響、ビジネス機会の損失などによる直接的または間接的なコストです。持ち運ぶデータを暗号化するという単純な対策を実施すれば、多くのデータ漏えいは防げます。

Windows Vista では BitLocker が導入され、Windows を実行するドライブ ボリュームを暗号化することによって、オフライン攻撃からオペレーティング システムを保護していました。トラステッド プラットフォーム モジュール (TPM) ハードウェア コンポーネントが存在する場合、BitLocker では、ブート処理の完全性が保証されます。これは、ブート処理の各ステップを検証し、ハッシュ チェックで問題が発生した場合にはブート処理を停止することで実現しています。ユーザーは常に独自の使い方を編み出すので、ベータ版の間に、BitLocker を使用して、ユーザーが所有しているデータを保護できることに気付きました。これを受けて、RTM 版では、いくつかのグループ ポリシー オブジェクト (GPO) と BitLocker を構成するユーザー インターフェイスが追加されましたが、(特に既存のコンピューターには) 展開するのが困難で、BitLocker はシステム ボリュームでしかサポートされませんでした。

Windows Vista SP1 では、BitLocker のサポートがすべてのハード ドライブに拡張され、3 つの方法 (TPM、USB のスタートアップ キー、ユーザー PIN) を組み合わせて暗号化キーを保護できるようになりました。また、既存のインストールで追加のハード ドライブ ボリュームの準備をするツールも提供されるようになりました。

Windows 7 では、BitLocker が必要な機能であると見なされ、そのセットアップが簡略化されました。インストール処理によって、必要なブート パーティションが自動的に作成されます。また、BitLocker は簡単に有効にできます。必要な操作は、ドライブ ボリュームを右クリックし、[BitLocker を有効にする] をクリックするだけです (図 2 参照)。コンピューターに複数のパーティションがなくても、準備処理によりドライブが再度パーティション分割されます。IT で管理されているデータ回復エージェント (DRA) により、キーの管理とデータの回復が簡単に行えるようになりました。DRA は、管理者が暗号化されている全ボリュームにアクセスできるようにするキーの保護機能です。DRA の使用は任意ですが、1 つ作成することを強くお勧めします。これをスマート カードに埋め込んで、カードをコンピューター室の金庫に保管して、ロックの組み合わせについての情報を共有する人選には慎重を期す必要があります。

figure2.gif

図 2 リムーバブル ドライブで BitLocker を有効にする (クリックすると拡大画像が表示されます)

以前は、BitLocker コントロール パネル アプレット、manage-bde.wsf コマンド ライン スクリプト、Windows Management Instrumentation (WMI) プロバイダーで、個別に構成オプションが提供されていました。Windows 7 では、BitLocker のすべてのオプションが、この 3 つの方法で使用できます。OS 以外のボリュームについては、自動ロック解除を制御して、スマート カード認証を義務付けられます (図 3 参照)。

figure3.gif

図 3 パスワードを使用して BitLocker で保護されているドライブのロックを解除する (クリックすると拡大画像が表示されます)

データ漏えいは、依然として多くの企業にとって大きな悩みの種です。小さなトラブルメーカーとも言える便利な USB ドライブが、問題の主な原因です (もちろん、これだけが原因というわけではなく、データは無数の方法で社外に出て行きます)。多くの企業にとって、利便性は欠くことができないので、USB ドライブの使用を制限したり、USB ポートを完全に無効にしたりする方法は役に立ちません。

Windows 7 では、BitLocker To Go を使用して、この問題を解決できます。ドライブを右クリックし、[BitLocker を有効にする] をクリックして、パスワードを作成すると、BitLocker To Go によって、ドライブの形式に関係なくドライブが暗号化されます (FAT 形式でフォーマットされているドライブでも機能します)。この機能により、ドライブを紛失した場合のリスクに対応できます。紛失したドライブには、重要な機密情報が保存されていることが多く、ドライブを盗んだ人がデータを盗用し、データの持ち主は WikiLeaks に機密情報を公開するほかありません。

BitLocker To Go は単なる USB プロテクターではありません。この機能では、任意の種類のリムーバブル ドライブを保護し、OS の BitLocker から独立した状態で機能します。ですから、"通常の" BitLocker 機能を使用する必要はありません。管理者は、BitLocker To Go で暗号化するまで、すべてのリムーバブル ドライブを読み取り専用にするというポリシーを構成できます (BitLocker To Go で暗号化すると、リムーバブル ドライブに書き込めるようになります)。また、保護されたデバイスにアクセスするのに認証 (名前と複雑さを選択できるパスワード、スマート カード、またはドメイン) を義務付けるポリシーを構成することもできます。DRA は、リムーバブル デバイスでも、ハード ドライブ ボリュームと同じように機能します。

Windows Vista と Windows XP コンピューターでは、ユーザーは、保護されたデバイスからデータを読み取ることはできましたが、データを書き込むことはできませんでした。BitLocker To Go では、物理ドライブに "検索ボリューム" を作成します (このボリュームには、BitLocker To Go リーダーとインストール手順が格納されます)。BitLocker To Go リーダーはダウンロードして入手することもできます。BitLocker To Go リーダーでアクセスできるのは、パスワードで保護されているボリュームのみで、スマート カードやドメインにはアクセスできません (図 4 参照)。

figure4.gif

図 4 BitLocker To Go リーダーを使用すると、以前のバージョンの Windows のデータに読み取り専用でアクセスできる (クリックすると拡大画像が表示されます)

AppLocker

ソフトウェア制限ポリシー (SRP) を使用したことはありますか。そもそも、SRP という言葉を聞いたことはありますか。SRP は Windows 2000 で導入された機能で、この機能を使用すると、管理者はコンピューターが "既定で許可" または "既定で拒否" のどちらの状態で動作するのかを制御できます。

"既定で拒否" が好ましいのは明らかだと思います。この場合は、実行を許可するソフトウェアを定義し、その一覧に含まれていないソフトウェアの実行はすべて拒否されます。SRP は、マルウェアの感染を防ぐのに適した方法です。ですが、SRP を使用すると、管理者の作業が増えるというのも事実です。パスの規則とハッシュの規則には、アプリケーションを構成している全 .EXE と .DLL を含める必要があります。また、ハッシュの規則は、アプリケーションが更新されるたびに差し替えが必要になります。社内で使用しているアプリケーションをすべて検出して追跡するのは気が遠くなるような作業です。一般的に SRP の規則は膨大になりますが、このような規則が想定外の誤操作を引き起こさないかどうかを確認するために必要となるテスト作業については、言うまでもないでしょう。SRP は、簡単に構成できず、実際に使用する機能としては柔軟性に欠けるので、あまり注目されませんでした。

ですが、セキュリティ設計において、アプリケーションの一覧を作成するのは重要な作業です。AppLocker では、作成するルールに柔軟性をもたらすことで、SRP の機能を向上します。また、通常の許可と拒否の規則に加えて、例外の規則を作成できます。このような方法で規則を運用すると、"既定で拒否" という状態を定義して管理するのが随分と楽になります。たとえば、「%WINDIR% ディレクトリにあるものは組み込みのゲーム以外すべて実行する」というルールを定義できます。ですが、デスクトップの背景を紫に変更することなどは制限しても意味がないと思います。計画に少し時間を費やすことで、管理しやすい一連の許可と例外の規則を使用して、実行しても問題のないアプリケーションの一覧を作成できます。

許可された発行元を定義する規則を作成することもできます (図 5 参照)。ユーザーがアプリケーションを実行すると、AppLocker では、アプリケーションの発行元のデジタル署名を定義済みの許可リストと比較し、指定されている他の条件を確認します。AppLocker で必要な規則は、SRP のハッシュ チェックよりも格段に少なくなっています。アプリケーションの全実行可能ファイルについて一連のハッシュの規則を確認する必要はなく、1 つの発行元の規則を確認するだけで済みます。発行元の規則を使用すると、実行を許可しているアプリケーションが更新された場合にも新しい規則を作成する必要がないというメリットがあります。たとえば、「バージョンが 9.0 以上の Acrobat Reader は実行します。ただし、Adobe による署名がなされていることが条件となります」という規則を作成できます。規則を作成した翌週に、Adobe でアプリケーションが更新されても、規則を差し替えることなく、アプリケーションをクライアントに配信できます。バージョン番号を指定することで、アプリケーション全体、特定のファイル、または一連のファイルを対象とした規則を作成できます。また、AppLocker では、規則を自動的に作成することもできます (図 6 参照)。

figure5.gif

図 5 AppLocker で発行元の規則を作成する (クリックすると拡大画像が表示されます)

figure6.gif

図 6 AppLocker では指定した種類の規則を自動的に生成できる (クリックすると拡大画像が表示されます)

SRP の規則はコンピューターにしか適用できませんでした。ですが、AppLocker の規則はユーザーにも適用できます。この機能は、コンプライアンスの要件を満たすのに役立ちます。たとえば、「人事部に所属している人だけが、人事部関連のアプリケーションを実行できるようにする」という規則を作成できます (ただし、厳密には、この規則には人事部に所属している人のユーザー アカウントがメンバーになっている Active Directory のセキュリティ グループが含まれています)。この規則では、人事部に所属していない人は管理者であってもブロックします。ですが、悪意のある管理者が規則を変更できるということを忘れないでください。私が以前に提唱した「信用できない管理者は、配置換えをせよ」という原則を思い出してください。

AppLocker がもたらす最大の機能強化は、この機能を実際に信用できるということです。正直なところ、SRP は、それほど堅牢ではありませんでした。オペレーティング システムによってポリシーが施行されていると思っていたかもしれませんが、それは正しくありません。アプリケーションの起動中には、OS ではなくアプリケーションの親プロセスが SRP を確認していました。管理者であるかどうかに関係なく、ユーザーが親プロセスを制御できる場合、ユーザーは SRP を回避できます。詳細については、Mark Russinovich のブログ記事「Circumventing Group Policy as a Limited User」(制限付きユーザー アカウントを使用してグループ ポリシーを回避する、英語) を参照してください。1 つ明白な概念をお知らせしましょう。セキュリティ機能としての役割を果たすには、その機能自体のセキュリティが確保されている必要があります。AppLocker は、サービスとカーネル モードのドライバーで構成されています。AppLocker の規則はドライバーで評価されるので、OS によってポリシーが施行されるようになります。なんらかの理由で AppLocker の規則ではなく、SRP の規則を引き続き使用する必要がある場合は、SRP の規則を堅牢にする必要があります。Windows 7 では、SRP API のデザインが見直されました。親プロセスは回避し、規則の実施とバイナリ ファイルの確認は AppLocker サービスで行われるようになっています。

ポリシーをテストする機能は重要です。AppLocker の監査機能では、規則を有効にした場合にアプリケーションがどのように動作するのかを確認できます (図 7 参照)。また、規則を有効にした場合に影響のある全ファイルが一覧表示されます。この一覧を使用して、規則を展開する前に発生する可能性のある問題を特定できます。規則では、.EXE、.DLL、.MSI、およびスクリプトを区別できます。AppLocker では、規則がトリガされる頻度の統計を取っています。この統計データは長期に渡って収集されるので、特に担当者が変更になったり、新しいアプリケーションが必要になったりした場合に役立ちます。

figure7.gif

図 7 AppLocker の監査モードを使用すると展開前に規則をテストできる (クリックすると拡大画像が表示されます)

DNSSEC

興味深いことに IPsec では sec という小文字表記が使用されているのに対して、DNSSEC はすべてが大文字表記です。といっても、これまで標準化団体が一貫性の化身だと言った人はいません。すみません。話が脱線しました。本題に戻りましょう。

以前、私は DNSSEC を信用していませんでした。DNS の応答に暗号化認証を設定すると、DNS を侵害できなくなるので、フィッシング攻撃を防げると言われていました。DNSSEC では、「名前解決のクエリ結果を信頼できるのか」という問題を解決しようとしました。ですが、この問題の捉え方は適切ではなく、「本物のサーバーにアクセスしていると思って良いのか」というのが適切な問題の捉え方だと思っていました。というのも、この問題には SSL で既に対応されていたからです。銀行のパブリック Web サイトの SSL 証明書を取得できるのは、本物の銀行だけでした。攻撃者が別のサイトにユーザーの要求をリダイレクトすることは可能でしたが、本物の銀行が使用している SSL 証明書を取得して、偽の Web サーバーをブラウザーで認証させることはできませんでした。IPsec も同様です。IPsec では、認証にデジタル証明書を使用しているので、第三者によってアクセス先が偽装されることはありません。

周囲からの穏やかな催促と甘言を吟味した結果、DNSSEC は重要な防御策の 1 つだと確信するに至りました。SSL と IPsec により適切なサイトに接続していることは保証されます。ですが、多くのユーザーは警告メッセージを無視することに慣れてしまったので、これらのテクノロジが役に立つかどうかは疑わしいものです。また、この 2 つのテクノロジには、適切なサイトへのアクセスが拒否されることを防ぐ機能がありません。DNS の侵害は、非常に効果的なサービス拒否攻撃 (DoS) で、このような攻撃は SSL や IPsec では防げません。ですが、DNSSEC では、このような攻撃を可能にする条件を排除できます。DNS サーバーからの応答には、リゾルバーで評価できるデジタル署名が含まれています。攻撃を可能にする "セキュリティ機能" は好きではないので、考えを改めました (アカウントのロックアウトも DoS 攻撃の経路になります)。そして、攻撃者が頻繁に乗っ取りを試みるルート サーバーを手始めに、インターネット中で DNSSEC を迅速に採用していることを好意的に受け止めるようになりました。

DNSSEC では、次の機能が提供されます。

  • 発行元の認証: 応答は、しかるべきサーバーから返されたものであることが保証されます
  • データの整合性: 転送中に応答が故意に変更されていないことが保証されます
  • 不在認証: ターゲットが存在しないことを示す応答はスプーフィングできません

DNSSEC 対応のサーバーでは、署名されたゾーンにあるレコードのクエリを受け取ると、応答と共にデジタル署名を返します。リゾルバーでは、サーバーの公開キーを取得して、応答を評価します。リゾルバーは、署名されたゾーンまたは親ゾーンの "トラスト アンカー" を使用して構成する必要があります。インターネットのルート サーバー上にある DNSSEC では、DNSSEC 対応のリゾルバーがトラスト アンカーをルートとすることが許可されています。

Windows 7 の DNSSEC クライアントは、セキュリティに対応した検証を行わないスタブ リゾルバーです。DNSSEC クエリを認識し、DNSSEC リソース レコードを処理しますが、応答の検証にはローカル DNS サーバーを使用します。リゾルバーでは、検証に成功した場合のみアプリケーションに応答を返します。クライアントとローカル DNS サーバー間の通信は SSL で保護されます。サーバーではクライアントに独自の証明書を提示します。DNSSEC の設定は NRPT で構成し、グループ ポリシーを使用して適用します (図 8 参照)。

figure8.gif

図 8 DNSSEC の名前解決ポリシーを構成する (クリックすると拡大画像が表示されます)

もう 1 つ重要なことがあります。これまで、公的な証明機関では、X.509 サーバー証明書についてアプリケーションを検証する義務を怠ってきました。攻撃者が実在する企業の役員になりすまして、信頼された証明書を不正に入手したという事例を見たことがあります。パブリック証明書が信頼性に欠けるという点で、SSL は、不完全だと考えられます。DNSSEC の標準では、企業が DNS サーバーの署名された証明書を受け取る前に、より厳格な確認と検証を行う必要があります。このようにすることで、オンライン トランザクションの信頼も回復できます。

その他の強化機能

ここまでは、私が気に入っているセキュリティ機能を紹介しましたが、このセクションでは、Windows 全体のセキュリティを向上するいくつかの強化機能を紹介します。

複数のアクティブなファイアウォール プロファイル。以前に執筆した記事で、サードパーティ製のファイアウォールを取り上げ、セキュリティの脅威にしかならない脅しをかけるような警告メッセージが表示されると指摘したことがあります (詳細については、「Windows ファイアウォールの調査」を参照してください。これについては、今でもそう思っています。Windows ファイアウォールでは、コンピューターを問題なく保護できます。ですが 1 つ制限事項があります。それは、3 つのプロファイルが定義されていても、一度にアクティブにできるのは 1 つだけだということです。社内のドメインに参加しているコンピューターでは自動的にドメイン プロファイルが使用されるので、管理のための着信通信を受け付けます。ホテルに滞在中は、コンピューターではパブリック プロファイルを使用するので、不要な着信通信がブロックされます。VPN を使用して社内ネットワークに接続しているときも、コンピューターではパブリック プロファイルが使用されるので、社外から接続しているコンピューターは管理ツールで認識されません。Windows 7 では、この制限がなくなりました。物理ネットワーク インターフェイスと仮想インターフェイスのどちらでも、パブリック プロファイル、プライベート プロファイル、またはドメイン プロファイルを個別に定義できます。

Windows 生体認証フレームワーク。指紋リーダーは、ありとあらゆる場所で見かけます。非常に安価なラップトップ コンピューターにも、指紋リーダーが搭載されています。以前のバージョンの Windows では組み込みのサポートが提供されていないので、指紋リーダーが使用されていないという状態が発生していますが、パソコン メーカーでは、ドライバーをインストールしたシステムを提供しています。このようなドライバーのコードの多くは品質が高くないため、ブルースクリーンが表示されるような状態が頻繁に発生しています。また、このような問題に遭遇した多くのユーザーは、律儀にもマイクロソフトに報告しています。

この情報を基に、マイクロソフトでは、OS にネイティブな生体認証のサポートを追加しました。ドライバーは、以前よりも高い品質を維持する必要があり、ユーザーには、コンピューター認証について、より多くの選択肢が提供されるようになりました。私は今でも ID (公的な宣言) と認証 (検証済みのシークレットを持っていること) は区別することが重要だと考えています。指紋は、確実に人の目に触れるものです。ですが、指紋認証によるログオンが適している場合もあります。体格の良い男性が大きな木箱やコンテナーに囲まれ、息を切らしながら働いている湾岸倉庫を思い浮かべてみてください。彼らは、カートに設置されたコンピューターで頻繁に在庫情報を更新する必要があります。粗大運動技術を使って 1 日の大半を過ごしている人が、突然、非常に薄いスマート カードを銀色のスロットに差し込むのに必要な細やかな運動技能を使うように頭を切り替えることができると思いますか。しかも、スマートカードは適切な方向に挿入する必要があります。このような切り替えを行うのは、おそらく無理でしょう。指紋認証を使用すれば、仕事のモードを切り替える必要はありません。ログインに必要な操作はリーダーに指をかざすだけです (これは実際に使用されているシナリオです)。

Windows 生体認証フレームワーク (WBF) は、生体認証をサポートする拡張可能な基盤です。Windows 7 の初期リリースでは、指紋認証のみがサポートされます。WBF では、生体認証ハードウェア、関連ドライバー、および登録ソフトウェアの信頼性を高めるいくつかのコンポーネントが定義されています。ユーザーが指紋の初期登録を行うと、生体認証サービスでは、このデータ ストリームとユーザーの資格情報を暗号化し、この情報を資格情報コンテナーという名前のデータ構造に保存します。暗号化されたパスワードには GUID が割り当てられ、これはハンドルとして機能します。重要なことですが、生体認証サービスでは、ユーザーのパスワードを直接アプリケーションに公開することはなく、ハンドルのみを公開します。指紋リーダーの機能によって異なりますが、指紋認証は、ローカル ログオン、ドメイン ログオン、および UAC 認証に使用できます。WBF を管理するための GPO もいくつか用意されています。

最強の Windows

昨年、自分のコンピューターに Windows 7 Beta1 をインストールしたとき、後ろを振り返ることはありませんでした。Windows 7 は、あらゆる点において優れていて、全体的な調整としあがり具合も好印象でした。アクセス、ユーザー、およびデータのセキュリティを確保する多面的なアプローチが用意されているので、ご使用のインフラストラクチャに追加する価値のある製品です。ポータブル コンピューター ユーザーからは間違いなく感謝されるでしょう。また、夢にまで見た状況が遂に現実のものとなり、「とりあえず、問題がないことをお知らせするために電話をしました」という連絡があるかもしれません。

Steve Riley は、世界の最先端を行っているプロバイダーでクラウド コンピューティングのエバンジェリスト兼戦略家として働いています。専門は、セキュリティ、可用性、信頼性、および統合性に関する企業要件です。連絡先は stvrly@gmail.com (英語のみ) です。