• [アーティクル]

セキュリティ

Windows 7 のセキュリティ概要

Chris Corio

この記事には、プレリリース コードに基づいている部分があります。ここに記載されているすべての情報は、変更される場合があります。

概要:

  • Windows 生体認証フレームワーク
  • 認証プロファイルを拡張する
  • BitLocker To Go
  • UAC の機能強化

目次

Windows 生体認証フレームワーク
認証プロトコルを拡張する
BitLocker の主な機能強化
BitLocker To Go
UAC の機能強化
AppLocker
グローバル SACL と詳細な監査
まとめ

Windows Vista では、さまざまな新しいセキュリティ テクノロジが導入され、Windows エコシステムは大きな影響を受けました。ユーザー アカウント制御では、Administrators グループに属していないユーザーでも Windows の実行が容易になることをマイクロソフトが目指していることが明確になりました。BitLocker では、Windows クライアントのフルボリューム暗号化機能が導入されました。また、保護モードの Internet Explorer は、インターネットをより安全に閲覧できるようにするのに役立ちました。

Windows 7 では、引き続きセキュリティに投資が行われており、新しいテクノロジを追加したり、Windows Vista で導入されたテクノロジの多くを強化したりしています。この記事では、Windows 7 の新しいセキュリティ機能と機能強化の概要を紹介します。

Windows 生体認証フレームワーク

Windows Vista では、Winlogon エクスペリエンスの再設計が行われました。このエクスペリエンスの再設計により、GINA (Graphical Identification and Authentication) インフラストラクチャが削除され、資格情報プロバイダの拡張モデルが追加されました。資格情報プロバイダ インフラストラクチャは、ユーザーが資格情報を入力する際のユーザー エクスペリエンスをサードパーティ製品が拡張した場合にも、一貫性を保つことができる一連のインターフェイスです。また、資格情報プロバイダ インフラストラクチャは、一般的な Windows の資格情報ダイアログ ボックスに統合されます。

Windows 7 では、Windows 生体認証フレームワーク (WBF) が新たに追加されました。指紋リーダーの普及が進んでいることから、開発を進め信頼性を高めるには、このようなテクノロジを公開、管理、および使用する共通のフレームワークの定義が必要なことは明らかでした。WBF は、生体認証デバイスのサポートを簡単にすることを目的としています。Windows 7 の WBF でサポートされているのは指紋リーダーだけですが、将来拡張される可能性があります。

WBF コア プラットフォームは、次の主要なコンポーネントで構成されています。

  • Windows 生体認証ドライバ インターフェイス (WBDI)
  • Windows 生体認証サービス (WBS)
  • WBF API
  • WBF ユーザー エクスペリエンスおよび統合ポイント
  • WBF の管理

Windows 生体認証ドライバ インターフェイス (WBDI) は、生体認証デバイスに共通のドライバ インターフェイスを提供することを目的としています。WBDI は、生体認証デバイスを生体認証フレームワークに統合するのに適したデータ構造と IOCTL (入出力制御) を公開する、さまざまなインターフェイスで構成されています。ドライバは、Windows Driver Model、カーネル モード ドライバ フレームワーク、ユーザー モード ドライバ フレームワーク (UMDF) など、あらゆる一般的なドライバ フレームワークに実装できます。ただし、生体認証デバイスに推奨されるドライバ フレームワークは UMDF です。これは、UMDF には、生体認証デバイス ドライバでクラッシュが発生した場合に、Windows で高い信頼性が確保されるという利点があるためです。

Windows 生体認証サービス (WBS) は、WBF を統合する重要なコンポーネントです。WBS は、生体認証デバイス ドライバと連動します。また、Windows 生体認証フレームワーク API を公開して、アプリケーションでこのようなデバイスを操作できるようにします。

WBS の重要な機能は、ユーザーの実際の生体認証データが特権のないアプリケーションには決して公開されないことです。パスワードとは異なり、生体認証による署名は、侵害された場合に変更するのが非常に難しいため、この機能は重要です。WBS では、生体認証データの代わりに、生体認証データをアプリケーションで間接的に操作できるようにするハンドル (通常は GUID または SID) が公開されます。

WBS では、生体認証デバイスのプールも管理されます。このため、生体認証デバイスの使用方法を制御できます。生体認証デバイスには、ログオン プロンプト、UAC プロンプトなどの資格情報ダイアログ ボックスで使用できるものもあります。たとえば、保護者による制限を自宅のコンピュータに設定できますが、昇格が必要なときは、指をデバイスにかざすだけで操作を昇格できます。この生体認証デバイスのプールは、システム プールと呼ばれます。デバイスのプールは、他に 2 つあります。1 つはプライベート プールです。このプールを使用すると、Windows 認証インフラストラクチャに統合されていない認証をアプリケーションで使用できます。もう 1 つは未割り当てのプールです。ご想像のとおり、このプールはシステム プールとプライベート プールのいずれにも該当しないデバイスを対象としています。

デバイス プールに含まれる各デバイスは、実際には WBS で生体認証ユニットと呼ばれるデータ クラスを使用して、抽象化されています。生体認証ユニットは WBS の生体認証サービス プロバイダ (BSP) に組み込まれており、BSP によって、一連の生体認証デバイスに固有のポリシーや動作が実装されます。生体認証ユニットを使用すると、特定のデバイスではサポートされない可能性のある機能 (デバイスで指紋データを取得した後に指紋データを保存したり、指紋データを処理したりする機能など) を BSP で提供できます。

WBF の 3 つ目の主要なコンポーネントは、一連の API (WinBio* API) です。アプリケーションやユーザー モード コンポーネントでこれらの API を使用して、デバイスを直接操作できます。たとえば、ユーザーの指紋を取得し特定のユーザー アカウントと関連付けるために原本を登録する処理、およびログオンや UAC でユーザーを検証する処理で、デバイスを操作できます。これらの API では、特定の生体認証デバイスに関するデータとその特性も公開されます。また、デバイス独自の機能をアプリケーションで操作できるように WBF API を拡張することもできます。

WBF では、生体認証デバイスの使用方法を構成する 2 つの主な方法を公開しています。エンド ユーザー向けにはコントロール パネル アプレットがあり、これは数か所で公開されています。コントロール パネルの [ハードウェアとサウンド] では、[生体認証デバイス] にアクセスできます。ここから、ユーザーはサードパーティ製の指紋管理アプリケーションを起動できます。Windows 7 には組み込みの指紋管理アプリケーションが用意されていないので、サードパーティ ベンダまたは OEM が独自の指紋管理アプリケーションを作成する必要があります (Windows 生体認証フレームワークでは、ローカル ログオンとドメイン ログオン、および組み込みの生体認証資格情報プロバイダを使用する指紋ベースの UAC がサポートされます)。

Windows 生体認証フレームワークは、グループ ポリシーを使用して管理することもできます。管理者は、フレームワーク全体を有効または無効にできるだけでなく、生体認証を使用できるログオンの種類を管理できます (たとえば、ローカル ログオンとドメイン ログオンを個別に構成できます)。

認証プロトコルを拡張する

Windows 7 では、ホームグループと呼ばれる機能によって、ホーム ネットワークや小規模ネットワークのエクスペリエンスが向上しています。ユーザーは、メディア ファイルなどのデータを家庭内のコンピュータで共有することが可能で、コンピュータ間の認証にはオンライン ID を使用します。この機能を有効にするには、ユーザーは Windows ユーザー アカウントとオンライン ID を明示的に結び付ける必要があります。認証は、公開キー ベースのユーザー間プロトコル (PKU2U) という新しいプロトコルによって実現されます。

Windows 7 では、Spnego.dll と呼ばれる、ネゴシエート認証パッケージの拡張も導入されます。SpNego は、認証時に使用する認証プロトコルを決定する機能です。Windows 7 以前では、認証方法として Kerberos と NTLM (Windows チャレンジ/レスポンス) のいずれかを選択するのが一般的でした。NegoEx 拡張は、Windows で認証プロトコルとして扱われ、マイクロソフトが提供している 2 つのセキュリティ サポート プロバイダ (PKU2U と Live) がサポートされます。他のセキュリティ サポート プロバイダを開発できるよう拡張することもできます。

どちらの機能も、オンライン ID を使用してホームグループ内の別のコンピュータに接続する際に動作します。あるコンピュータから別のコンピュータに接続する場合は、ネゴシエートの拡張によって、ログイン先のコンピュータで PKU2U セキュリティ サポート プロバイダが呼び出されます。そして、PKU2U セキュリティ サポート プロバイダによって証明機関のポリシー エンジンから証明書が取得され、ピア コンピュータ間でポリシー (およびその他のメタデータ) が交換されます。ピア コンピュータ上で検証する場合は、証明書がログオン先のピア コンピュータに送信されて検証され、ユーザーの証明書がセキュリティ トークンにマップされて、ログオン プロセスが完了します。

BitLocker の主な機能強化

Windows Vista では、BitLocker が導入されました。BitLocker はフルボリューム暗号化ソリューションで、コンピュータを紛失したり、コンピュータが悪意のある人物の手に渡った場合にもラップトップ コンピュータやデスクトップ コンピュータ (ブランチ オフィス サーバーなど) のデータを保護することを目的としています。Windows 7 では、BitLocker の管理機能に対して大幅な機能強化が施されました。たとえば、すべてのインターフェイス (UI、manage-bde コマンド ライン ツールおよび WMI プロバイダ) で同じように適用したり、固定データ ドライブに個別のグループ ポリシーを設定したりすることができます。また、パスワードを更新したり、OS 以外のドライブをスマート カードと統合したりすることができる、新しいグループ ポリシー設定があり、自動ロック解除の動作を変更することもできます。

Windows Vista では、BitLocker のインストール要件に合わせて OS のドライブをパーティション分割することが難しく、特にオペレーティング システムを既にインストールしている場合は難しいという意見が寄せられていました。この問題は、Windows 7 に施された 2 つの機能強化によって解決されています。まず、既定では Windows 7 のセットアップ中に、BitLocker が OS のドライブで機能するために必要な、独立したアクティブなシステム パーティションが作成されます。このため、多くの環境で必要だった追加作業が不要になります。また、独立したシステム パーティションがない場合は、BitLocker のセットアップ中に、BitLocker 用のドライブをパーティション分割できます (図 1 参照)。

fig01.gif

図 1 BitLocker 用ドライブの準備

BitLocker To Go

BitLocker To Go は、最もわかりやすく、最も重要な追加機能の 1 つです。これは、リムーバブル データ ドライブのデータを保護することを目的としています。BitLocker To Go を使用すると、USB フラッシュ ドライブや外付けハード ドライブで BitLocker ドライブ暗号化を構成できます。BitLocker To Go の設計目標では、この機能を使いやすくすること、既存のドライブで動作すること、必要に応じてデータを回復できるようにすること、およびデータを Windows Vista と Windows XP のシステムで使用できるようにすることを掲げていました。

この機能では、IT 管理者向けの多くの管理機能が強化されました。最も注目に値するのは、BitLocker To Go で暗号化されていないリムーバブル ドライブを読み取り専用に構成できる、新しいグループ ポリシー設定です。これは、従業員が USB フラッシュ ドライブを紛失した場合に重要な企業データが保護されるようにするうえで、すばらしい進歩です。

また、データにアクセスできない場合に、BitLocker To Go デバイスのデータを回復できる機能も注目に値します。データ回復エージェントと呼ばれるこのテクノロジは、暗号化ファイル システム (EFS) 機能から移植されたもので、企業が作成したキーを使用してポータブル ドライブに格納されている企業データを簡単に回復できます。

BitLocker To Go 機能を Windows XP や Windows Vista で有効にするには、BitLocker の中核機能を再設計する必要がありました。再設計に際して、開発チームでは、BitLocker で FAT ボリュームの保護に使用するメソッドをリファクタリングしました。BitLocker の動作を変更し、物理的な元のボリューム上に "探索ボリューム" を重ねて、上書きされるブロックが仮想化されるようにしました。探索ボリュームには、BitLocker To Go リーダーと Readme ファイルが格納されています。これは、ハイブリッド BitLocker ドライブと呼ばれます。既定では、FAT ドライブが暗号化されると、ハイブリッド BitLocker ドライブが作成されます。探索ドライブは、Windows XP オペレーティング システムと Windows Vista オペレーティング システムのみで表示されます。

また、Windows 7 のリリース後、BitLocker To Go リーダーは Microsoft ダウンロード センターで提供される予定です。このアプリケーションを使用すると、パスワード キーの保護機能を使用する BitLocker ドライブに読み取り専用でアクセスできます。ただし、BitLocker To Go リーダーを使用している場合はスマート カード認証を使用できないことに注意してください。

UAC の機能強化

ユーザー アカウント制御 (UAC) は、誤解されることの多いテクノロジです。まず、UAC は単独のプロンプトはなく、実際は一連の機能で構成されています。このような機能には、ファイルとレジストリのリダイレクト、インストーラの検出、UAC プロンプト、ActiveX インストーラ サービスなどがあります。これらの機能はすべて、Administrators グループのメンバではないユーザー アカウントで Windows を実行できるようにすることを目的にしています。このようなアカウントは、一般に標準ユーザーと呼ばれ、大雑把に言うと最小限の特権で OS を実行するアカウントです。重要な点は、ユーザーが標準ユーザー アカウントで OS を実行すると、通常、操作の安全性と信頼性が大幅に高まることです。

多くの開発者は、アプリケーションが標準ユーザー アカウントで正常に機能するように対処し始めています。企業では標準ユーザー アカウントを展開することが明確になったので、サポート費用とコンピュータの全体的な TCO (総保有コスト) を削減できました。また、家庭では、保護者による制御と共に、子供向けに標準ユーザー アカウントを使用して、より安全な環境を実現できます。

Windows 7 には、標準ユーザーのエクスペリエンスを向上する機能強化が多数用意されており、新しい構成設定を使用すると、管理者承認モードではユーザー アカウント制御のプロンプトをより詳細に制御できます。その目的は、使いやすさを向上しながら、独立系ソフトウェア ベンダに対して、対応する必要がある既定のセキュリティ コンテキストが標準ユーザーのセキュリティ コンテキストであることを明確にすることです。実際、このような変更によって、Windows 7 の通常の管理タスクではユーザーにメッセージが表示されることがなくなりました。これは、[既定 - プログラムがコンピューターに変更を加えようとする場合のみ通知する] という設定によるものです。

この設定が機能するしくみは実に簡単です。プロセスの作成時に、ポリシーでこの設定が有効になっているかどうかが確認されます。作成されるプロセスが Windows に含まれている場合、プロセスは、Windows のカタログ ファイルで署名を確認することで検証されるので、プロンプトが表示されずにプロセスが作成されます。この設定を使用すると、Windows の設定を変更する際にメッセージが表示されず、ユーザーは Windows 以外のアプリケーションによって要求された管理上の変更 (新しいソフトウェアのインストールなど) に集中できます。通知が表示されることなく Windows の設定を頻繁に変更できるという、よりきめ細かい制御が必要な場合は、この設定を有効にすると、全体的なメッセージの数が減少し、実際に表示される重要な通知にユーザーが集中できるようになります。

もう 1 つの重要な変更点は、いくつかのコンポーネントで管理者特権が不要になったことです。たとえば、ユーザーはデスクトップを高 DPI モードで表示するかどうか構成できます。高 DPI モードでは、コンピュータの画面が大きくなり、ピクセル サイズが小さくなるので、よく使用される機能です。また、標準ユーザーは、コンピュータに物理的にアクセスしてログインしている場合にネットワーク接続をリセットできるようになりました。これは、ホーム ユーザーと企業ユーザーの両方からマイクロソフトによく寄せられていた要望です。

fig02.gif

図 2 ActiveX コントロールをインストールする際のユーザー アカウント制御

メッセージの数が減少すると、1 つのユーザー操作に対して複数のメッセージが表示される場合も少なくなります。たとえば、Windows 7 では、Internet Explorer で ActiveX コントロールをインストールする操作が非常にスムーズに行えるようになりました。Windows Vistaでは、Internet Explorer 7 によって、ActiveX コントロールのインストールを実行する IEInstal.exe プロセスが作成されました。このため、IE のアドオンのインストールを管理者権限で実行するかどうか確認する UAC プロンプトが表示されました。このプロンプトには、インストールされる ActiveX コントロールに関する具体的な詳細情報が提示されず、すぐに Internet Explorer からコントロールを承認するよう要求されました。Internet Explorer 8 が同梱された Windows 7 では、ActiveX インストーラ サービスを使用するようにインストール処理が変更されました。ActiveX インストーラ サービスでは、ActiveX コントロールの発行元情報を抽出して、インストール処理中に表示します (図 2 参照)。この新しい手法では、以前 ActiveX コントロールのインストール中に表示されていた 2 つ目のプロンプトも表示されなくなります。

AppLocker

ユーザーまたは一連のユーザーが実行できるアプリケーションを制御する機能を使用すると、企業のデスクトップ コンピュータの信頼性とセキュリティが大幅に向上します。概して、アプリケーションのロックダウン ポリシーを使用すると、企業ではコンピュータの TCO を削減できます。Windows 7 では、AppLocker という新機能が追加されました。AppLocker によって、アプリケーションの実行が制御され、企業では、アプリケーション ロックダウン ポリシーをさらに簡単に作成できるようになります。

私は Durga Prasad Sayana と、昨年のセキュリティ特集の記事「ソフトウェア制限ポリシーを使用したアプリケーションのロックダウン」でアプリケーションのロックダウン ポリシーについて説明しました。この記事では、このようなポリシーを作成する場合に企業で克服する必要があるさまざまな課題について説明しました。このような課題には、次のようなものがあります。

  • 環境で使用されているソフトウェアを把握する
  • さまざまなユーザーが実行を許可される必要があるアプリケーションを把握する
  • 必要なポリシーを作成する方法を把握する
  • 展開時にポリシーが正常に機能するかどうかを確認する

このような課題に対処するために、AppLocker では、アプリケーションのロックダウン ポリシーの動作方法を監査する新しい方法が提供されます。AppLocker では、すべての種類のアプリケーション (実行可能ファイル、スクリプト、Windows インストーラ ファイル、および DLL) をユーザーが実行する方法を制御できます。また、新しいアプリケーション ロックダウン ポリシーのプリミティブが提供されます。このプリミティブは、さらに具体的で、アプリケーションの更新時にポリシーが無効になりにくくなっています。Windows 7 では、従来のソフトウェア制限ポリシー (SRP) の規則もサポートされますが、Windows XP と Windows Vista では新しい AppLocker の規則はサポートされません。

実施のモードはすべて、AppLocker の基盤となっている実施エージェントに実装され、このエージェントは appid.sys ドライバに実装されています。このドライバでは、カーネル モードの規則でプロセスの作成や DLL の読み込みなどのイベントを確認する機能が提供されます。ユーザー モードでの実施を実装するアプリケーションでは、従来の SaferIdentifyLevel API を使用して、アプリケーションを実行できるかどうかが判断されます。しかし、SaferIdentifyLevel API では、バイナリとポリシーを実際に検証するサービスに、実施するかどうかの調査が渡されるようになりました。これは、従来のソフトウェア制限ポリシーの機能にはない、アーキテクチャ上の大きな機能強化です。

AppLocker の目的は、IT プロフェッショナルが、実行を許可されているすべてのアプリケーションを表す単純な規則のセットを簡単に作成して、この規則がアプリケーションの更新に対応できるようにすることです。

AppLocker ポリシーを作成するために、グループ ポリシー オブジェクト エディタのユーザー エクスペリエンスに新しい AppLocker MMC スナップインのユーザー エクスペリエンスが追加されています。このスナップインによって、AppLocker の規則の作成処理が大幅に向上します。単一の規則を作成できるウィザードや、規則の設定と選択したフォルダに基づいて、複数の規則が自動的に生成されるウィザード (図 3 参照) があります。

fig04.gif

図 3 AppLocker ポリシーの規則の自動生成

解析されたファイルを確認して、規則が作成される前に一覧からファイルを削除することができます。ファイルがブロックされた頻度に関する有益な統計データを取得したり、指定したコンピュータに対して AppLocker ポリシーをテストしたりすることもできます。

従来のソフトウェア制限ポリシーでは、安全で、かつソフトウェアの更新で無効にならないポリシーを作成するのは非常に困難でした。これは、証明書の規則がきめ細かくなく、アプリケーションのバイナリが更新されると無効になるほどハッシュの規則が脆弱だったためです。この問題に対処するために、AppLocker では、証明書を製品名、ファイル名、およびファイル バージョンと結び付ける規則を作成できるようになりました。このため、特定のベンダが特定の製品名に対して署名したあらゆるアプリケーションを実行できるよう簡単に指定できます。

Windows 7 の AppLocker には、さまざまな種類の実行ファイル (EXE、DLL、MSI、またはスクリプト ホスト) の分離など、他にも利点があります。このようなファイルの種類は、規則のコレクションと呼ばれる 4 つの種類に分類され、それぞれの種類に対して別々の実施方法を構成します。たとえば、管理者は実行可能ファイルに対する AppLocker の確認を有効にし、スクリプト ファイルに対する確認を無効することができます。

AppLocker ポリシーは、HKLM\Software\Policies\Microsoft\Windows\SrpV2 キーに格納されています。ポリシーは XML 形式で格納され、アプリケーション ID (AppID) サービスによって変換されます。ポリシーが処理されると、AppID サービスでは、IOCTL_SRP_POLICY を使用して新しいポリシーを appid.sys ドライバに通知し、ドライバではポリシーが再度読み込まれます。

IT 環境を変更する際には、まず、IT 環境が現在どのように機能しているかを評価する必要があります。環境を評価したら、変更点をスムーズに実装できるように、変更内容を慎重に計画してテストできます。これが、監査のみの実施モードの目的です。

AppLocker ポリシーの実施を監査することは、非常に重要です。監査では、実施前にポリシーをテストできるだけではなく、有効期間中にポリシーが、どのように実施されるのかを監視する機能も使用できます。ある時点で特定のユーザーがアプリケーションを実行する必要があったかどうかを確認したいと思うことがあるでしょう。これを判断するには、システムに接続して AppLocker の監査情報を確認し、アプリケーションのロックダウン ポリシーによって特定のアプリケーションの実行がブロックされたかどうかを確認します。

AppLocker イベントを確認できる主な場所は、イベント ビューア (eventvwr.msc) アプリケーションの [アプリケーションとサービス ログ] です。これらのログ エントリを表示するには、Microsoft\Windows\AppLocker\ イベント チャネルで、EXE and DLL ログおよび MSI and Script ログを参照します。アプリケーションが許可またはブロックされたかどうか、ポリシーがシステムに対して実施されたかどうかなど、さまざまなイベントが生成されます。

DNSSec による検証

この数年間で、DNS に関する攻撃は、インターネットでますます一般的な問題になっています。DNS サーバーに危害を加える方法が詳しく知られるようになり、攻撃者は DNS の情報を利用し始めています。このため、ユーザーが Web サイトにアクセスする際、知らないうちに別の悪意のある Web サイトにアクセスしてしまう可能性があります。

Windows Server 2008 R2 および Windows 7 では、現在の標準 (RFC 4033、RFC 4034、および RFC 4035) に準拠した DNSSEC のサポートが導入されています。Windows Server 2008 R2 では、DNS サーバーで公開元の機関やデータの整合性の成果物を提供できます。基本的にサーバーでは、返される DNS データにデジタル署名を行い、他の DNS サーバーから受信したデータを検証したりすることができます。

Windows 7 は、クライアントが DNS サーバーと安全に通信していることを検証したり、サーバーでクライアントの代わりに DNSSEC が実行されていることを検証したりするために必要な要素が用意されている、最初のクライアント オペレーティング システムです。このテクノロジは、現在のインターネット インフラストラクチャとの互換性を最大限確保するために現在テスト中で、今後も DNS データをセキュリティで保護する役割を果たすことを目指しています。

グローバル SACL と詳細な監査

Windows 7 では従来の監査メカニズムが拡張され、オブジェクトだけではなくユーザーに対する監査を管理できる新機能が提供されるようになり、ファイル オブジェクトの AccessCheck エラーに関してより詳細な情報が提供されるようになりました。このため、新しい監査のシナリオが可能になり、監査に関連するパラダイムが大きく変化しました。

他のバージョンの Windows では、オブジェクトのアクセスを監査するかどうかは、オブジェクトのセキュリティ記述子の SACL に、オブジェクトの監査を指定するアクセス制御エントリ (ACE) が含まれているかどうかによって判断されていました。このため、非常に簡単にレジストリ キーやファイルを監視して、そのオブジェクトへのアクセスを確認できました。しかし、残念ながら、特定のユーザーがアクセスしている対象を監視する方法はありませんでした。このようなシナリオに対応する必要がある場合は、ユーザーが操作する可能性のあるすべてのリソースの監査を有効にする必要があり、結果として、リソースに対する全ユーザーによるすべてのアクセスが監査ログに記録されました。

ユーザーがアクセスする可能性のある全リソースを含むほど広範なデータ セットに対して監査を有効にするのは、非常に困難な作業です。SACL に監査ポリシーが含まれるようにすべてのリソースを更新する必要があり、このポリシーに対する変更で、すべての SACL を更新する必要があります。この制限を回避するために、Windows 7 ではグローバル オブジェクト アクセスの監査が導入されました。この機能は auditpol.exe によって管理され、グループ ポリシーを使用して構成できます。

グローバル オブジェクト アクセスの監査には、"グローバル SACL" という、他の監査関連データと共にレジストリに格納された SDDL 文字列が含まれています。グローバル SACL の管理用に、AuditSetGlobalSacl と AuditQueryGlobalSacl という 2 つの新しい API が追加されています。グローバル SACL を更新するには、SeSecurityPrivilege が必要です。これにより、管理者権限のないユーザーによってグローバル SACL が更新されることから保護しています。

Windows 7 のセキュリティ監査では、オブジェクトへのアクセスが失敗または成功した理由を把握できる機能も提供されます。アプリケーション エラーをデバッグしたり、セキュリティ ポリシーの有効性を特定したりしている場合、これは重要な情報です。グローバル オブジェクト アクセスの監査機能と詳細なアクセス監査データの追加は、どちらも新しいカーネル モードのセキュリティ API (SeAccessCheckEx) に実装されています。この API を使用する 2 つのリソース マネージャは、NTFS および Windows 7 の詳細なファイル共有になるでしょう。これらが有効な場合、アクセスの試行が成功または失敗した理由に関する情報が API によって監査ログに記録されます。このように、この機能は、現時点ではファイルシステムとファイル共有に適用されていますが、今後リリースされるバージョンの Windows では他のリソース マネージャに拡張される可能性があります。

まとめ

Windows 7 では新しいシナリオが可能になり、Windows の操作の安全性が高まります。このような機能の多くは (ホーム ユーザー、ビジネス ユーザー、および IT プロフェッショナルの) ユーザー エクスペリエンスに重点を置いており、Windows 7 システムがさらに効果的に機能するのに役立ちます。

Chris Corio は、5 年以上にわたりマイクロソフトの Windows セキュリティ チームに所属していました。マイクロソフトでは、主にアプリケーションのセキュリティに関するテクノロジと、Windows をセキュリティで保護するための管理テクノロジを担当していました。連絡先は winsecurity@chriscorio.com (英語のみ) です。