サービスおよびサービス アカウントのセキュリティ計画ガイド
-
[アーティクル]
-
-
第 2 章 - サービスのセキュリティを保護して実行するためのアプローチ
最終更新日: 2006年2月1日
ダウンロード
.gif)
サービスおよびサービス アカウントのセキュリティ計画ガイド (英語)
この章では、サービスの実行時固有のリスクの詳細と、サービスの実行に使用されるアカウントの種類について説明します。また、サービスのセキュリティを保護して実行する方法を計画するときに適用する原則と戦略についても説明します。
トピック
サービスの脆弱性
システム アカウント
ユーザー アカウント
Windows Server 2003 の既定のセキュリティ設定の変更
サービスのセキュリティを保護して実行するための原則
サービスの脆弱性
サービスはスタートアップ時にユーザーが介在しないで実行されるので、Web サービスなどのサーバー型のアプリケーションに適しています。ただし、サービスが実行されていることにユーザーが気付かないことがあるので、この特性には短所もあります。サービスによっては、ユーザーに表示されるウィンドウやダイアログ ボックスを開くものもあります。しかし、一般にはユーザーがサービスと対話することはほとんど、またはまったくないため、多くの既定のサービスが実行され、潜在的なセキュリティ リスクを認識しない場合があります。Nimda などの最近のインターネット ワームは、Web サーバーがユーザーの認識なしにワークステーションで実行されるという事実を悪用します。ウイルスに感染したワークステーションによって、インターネット上の多くのコンピュータにワームが拡散されます。
一部のサービス、特に Microsoft® Systems Management Server、Microsoft Operations Manager、Tivoli など、エンタープライズ管理ツールで使用されるサービスは、一般にドメイン全体へのアクセス、および他の信頼されるドメインへのアクセスも必要になるので、ドメイン ユーザー アカウントを使用してログオンする必要があります。他のシナリオでもドメイン ユーザー アカウントを使用してサービスを実行することは、かつては標準的な方法でしたが、最近この方法はセキュリティのリスクとして認識されるようになりました。
ドメイン ユーザー アカウントやローカル ユーザー アカウントを使用する各サービスのユーザー名とパスワードの情報は、レジストリに保存されます。攻撃者はコンピュータの管理アクセス権を得るときにレジストリを悪用する可能性があります。このため、ユーザーとしてログオンするようにサービスを構成すると、常にセキュリティが危険にさらされます。
ドメイン ユーザー アカウントとしてログオンするようにサービスを構成すると、常にセキュリティが危険にさらされます。このため、次のようなさまざまな要因に基づいて、この脆弱性が悪用される可能性が高まります。
サービスの実行に特定のドメイン ユーザー アカウントを構成しているサーバーの台数 : 厳重に管理されたサーバー環境では、すべてのサーバーは一様にセキュリティで保護されます。組織がすべてのサーバーを一様にセキュリティで保護しないと、セキュリティの保護が不十分な各サーバーが悪用される可能性が高まります。ドメインで認証されたサービスを実行するサーバーが増加すると、セキュリティの脆弱性を悪用する攻撃者の危険性も高まります。たとえば、あるサービスが同じドメイン アカウントを使用して、組織内の莫大な数のサーバーで認証を受けるとします。その結果、攻撃者はこのようなサーバーのうち 1 台に侵入して、サービスが使用するユーザー名とパスワードを盗むと、そのサービスが実行される他のすべてのサーバーにアクセスできます。
サービスを実行するように構成されたすべてのドメイン ユーザー アカウントのネットワーク特権の範囲 : 特権の範囲が広くなればなるほど、危険にさらされるリソースの数が増加します。ネットワークの脆弱性の範囲は、ドメインに存在するすべてのコンピュータ (ドメイン コントローラを含みます) に及ぶので、ドメイン管理者アカウントのリスクは高くなります。その上、このドメイン ユーザー アカウントが 1 台以上のサーバーのローカル管理者特権を持つと、セキュリティの脆弱性が繰り返し悪用される可能性があります。
ドメイン管理者の資格情報によって脆弱性が推移し、ドメイン全体で特権昇格の機会が出てくるので、管理者レベルのアカウントがアクセスするネットワーク リソースを保護することが特に重要です。これらの資格情報は、一般的にドメイン内のすべてのコンピュータでの対話型ログオンやリモート ログオンに使用されます。したがって、資格情報が危険にさらされると、ドメイン内のすべてのコンピュータが攻撃に対して脆弱になります。
サービスの脆弱性のシナリオ
サービスの脆弱性には、セキュリティ リスクのレベルが異なるいくつかのシナリオがあります。次の図と表で、これらのシナリオについて説明します。次の図のすべてのアカウントは、ドメイン アカウントであるとします。各アカウントは、1 台のサーバーで少なくとも 1 つのサービスを実行しています。
次に、図のドメイン アカウントについて説明します。
アカウント A は、2 台以上のドメイン コントローラに管理者と同等の特権があります。
アカウント A、B、C、および D は、2 台以上のメンバ サーバーに管理者と同等の特権があります。
アカウント E は、1 台のメンバ サーバーのみに管理者と同等の特権があります。
.gif)
図 2.1: ドメイン コントローラとサーバーの管理者アカウントの特権
全画面表示
セキュリティの脆弱性の優先順位
次の表で使用されているリスクの優先順位レベルは次のとおりです。
緊急リスク レベル : 企業のセキュリティを直ちに危険にさらします。
高リスク レベル : 企業のセキュリティを危険にさらしますが、セキュリティが直ちに危険にさらされるわけではありません。
中リスク レベル : 重要ですが、セキュリティの危険性は、セキュリティが厳格なサーバーには関係しません。
低リスク レベル : 無視しても、セキュリティの目標にほとんど影響がありません。
次の表で、サービスの脆弱性のシナリオ、および脆弱性の優先順位レベルについて詳しく説明します。
表 2.1: セキュリティの脆弱性のシナリオ
| 1 |
アカウント A はサーバー 1 でサービスを実行しています。アカウント A のパスワードがサーバー 1 で明らかになると、ユーザーは DC 1 にアクセスできます。これにより、DC 1 が脆弱になります。これは優先順位が "緊急" の場合です。ドメイン コントローラで管理者と同等の特権のあるドメイン アカウントを使用して、メンバ サーバーでサービスを実行すべきではありません。 |
緊急 |
| 2 |
アカウント B はサーバー 2 でサービスを実行しています。アカウント B は、アカウント A がサービスを実行しているサーバー 1 にもアクセスできます。アカウント B のパスワードがサーバー 2 で明らかになると、シナリオ 1 と同じ開始状態になります。これにより、DC 1 が脆弱になります。この論理を、アカウント C がサーバー 3 でサービスを実行する場合にも拡張できます。つまりアカウント B がサービスを実行するサーバー 2 へのアクセスが可能になり、順次サーバー 1 にもアクセスできるようになります。これは優先順位が "高" の場合です。シナリオ 1 の問題が解決されると、シナリオ 2 の問題はメンバ サーバーのみに限定されるので、緊急ではありません。 |
高 |
| 3 |
アカウント D はサーバー 4 またはサーバー 5 でサービスを実行しています。アカウント D のパスワードがサーバーで明らかになると、ユーザーはアカウント D が特権を持つすべてのメンバ サーバーにアクセスできます。これは優先順位が "中" の場合です (シナリオ 2 の推移性はありません)。 |
中 |
| 4 |
アカウント E はサーバー 5 でサービスを実行していて、サーバー 5 のみにアクセスできます。 |
低 |
#### サービスの脆弱性のまとめ
ローカル サーバーやネットワーク上の他のサーバーにアクセスする攻撃者にとって、サービスが最も脆弱なポイントになります。不要なサービスがある場合は、無効にする必要があります。不要なサービスを無効にすることで、攻撃を受けやすい範囲をすばやく簡単に減らすことができます。不要なサービスを実行しないことによって、パフォーマンスが向上します。
サービスを正しく保護するには、サービスの脆弱性を認識し、脆弱性の危険性を最小限に抑える必要があります。
[](#mainsection)[ページのトップへ](#mainsection)
### システム アカウント
サービスは、アカウントとしてログオンしないと、オペレーティング システムのリソースやオブジェクトにアクセスできません。ログオンのための適切なアクセス許可のないサービスにアカウントを割り当てる場合、Microsoft 管理コンソール (MMC) のサービス スナップインによって、管理されるコンピュータの "サービスとしてログオン" ユーザー権利が自動的に許可されます。Microsoft Windows Server™ 2003 には、さまざまなシステム サービス用のログオン アカウントとして使用する、次の 3 つのビルトイン ローカル アカウントがあります。
- **ローカル システム アカウント**
ローカル システム アカウントは、サービスを開始し、そのサービスにセキュリティ コンテキストを提供できる、定義済みのローカル アカウントです。ローカル システム アカウントは、ドメイン コントローラで実行されるサービスに使用されると、ディレクトリ サービスを含めてコンピュータに完全にアクセスできる強力なアカウントです。このアカウントはネットワーク上のホスト コンピュータのアカウントとして動作するので、他のすべてのドメイン アカウントとまったく同様にネットワーク リソースにアクセスできます。ネットワーク上では、このアカウントは DOMAIN\\<コンピュータ名>$ と表示されます。サービスがローカル システム アカウントを使用してドメイン コントローラにログオンすると、ドメイン コントローラ自体にローカル システムのアクセス許可を持つことになります。ドメイン コントローラが侵害されると、悪意のあるユーザーは希望するドメインであらゆる変更を行うことができます。Windows Server 2003 では、いくつかのサービスを既定でローカル システム アカウントでログオンするように構成しています。アカウントの実際の名前は、NT AUTHORITY\\System です。このアカウントには、管理者が管理すべきパスワードがありません。
- **Local Service アカウント**
Local Service アカウントは、認証済みのローカル ユーザー アカウントと同様の、特権の低い特殊なビルトイン アカウントです。このアカウントの制限付きのアクセス許可は、攻撃者が個別のサービスやプロセスを侵害した場合の防御策として有効です。Local Service アカウントで実行されるサービスは、NULL セッションとしてネットワーク リソースにアクセスします。つまり、匿名の資格情報を使用します。アカウントの実際の名前は、NT AUTHORITY\\LocalService です。このアカウントには、管理者が管理すべきパスワードがありません。
- **Network Service アカウント**
Network Service アカウントは、認証済みのローカル ユーザー アカウントと同様の、特権の低い特殊なビルトイン アカウントです。このアカウントの制限付きのアクセス許可は、攻撃者が個別のサービスやプロセスを侵害した場合の防御策として有効です。Network Service アカウントとして実行されるサービスは、ローカル システム サービスと同じ方法で、コンピュータ アカウントの資格情報を使用してネットワーク リソースにアクセスします。実際のアカウント名は、NT AUTHORITY\\NetworkService です。このアカウントには、管理者が管理すべきパスワードがありません。
**重要 :** 既定のサービス設定を変更すると、主要なサービスが正しく実行されない場合があります。既定で自動的に開始するよう設定されているサービスの \[スタートアップの種類\] と \[ログオン方法\] の設定を変更するときは特に注意が必要です。
[](#mainsection)[ページのトップへ](#mainsection)
### ユーザー アカウント
ユーザー アカウントのいくつかのカテゴリは、サービスとしてログオンできます。どのカテゴリのアカウントにも、それぞれ固有の機能と特権があります。
- **ローカル ユーザー アカウント**
このカテゴリには、コンピュータにローカルに作成するアカウントが含まれます。たとえば、ローカル ユーザーとグループ管理コンソールで作成するアカウントです。これらのアカウントは、具体的に高い特権を許可するか、既に高い特権のあるグループに追加しない限り、ローカル コンピュータでは非常に限定された特権しかありません。
- **ローカル管理者アカウント**
このカテゴリには、コンピュータに Windows Server 2003 や Microsoft Windows® XP を初めてインストールするときに作成および使用される、ビルトイン Administrator アカウントが含まれます。また、インストール後に作成してビルトイン Administrators グループに追加した他のユーザー アカウントもこのカテゴリに含まれます。このグループのメンバは、ローカル コンピュータに完全かつ無制限にアクセスできます。
- **ドメイン ユーザー アカウント**
このカテゴリには、ドメインで作成するアカウントが含まれます。たとえば、Active Directory® ユーザーとコンピュータ管理コンソールを使用して作成するアカウントです。これらのアカウントは、具体的に高い特権を許可するか、既に高い特権のあるグループに追加しない限り、ドメインでは非常に限定された特権しかありません。
- **ドメイン管理者アカウント**
このカテゴリのアカウントには、Active Directory を最初にインストールしたときに作成および使用される、ビルトイン ドメイン Administrator アカウントなどがあります。また、インストール後に作成してビルトイン ローカル Administrators グループまたは Enterprise Admins グループに追加したユーザー アカウントも、このカテゴリに含まれます。これらのグループのメンバは、ドメイン (Enterprise Admins グループの場合はフォレスト全体) に完全かつ無制限にアクセスできます。
[](#mainsection)[ページのトップへ](#mainsection)
### Windows Server 2003 の既定のセキュリティ設定の変更
Windows XP および Windows Server 2003 以前にリリースされたバージョンの Windows では、オペレーティング システムに含まれるほぼすべてのサービスは、既定でローカル システム アカウントを使用していました。このコンテキストで実行されるプログラムには、ローカル コンピュータに無制限の特権があり、明らかにセキュリティ リスクをもたらします。Windows Server 2003 のリリースでは既定の設定を変更し、環境のセキュリティを高めました。これらの変更点の 1 つに、既定でローカル システム アカウントで実行されるサービスの数を減らしたことがあります。多くの共通サービスが、ローカル システム アカウントを使用する代わりに、Local Service アカウントまたは Network Service アカウントを使用するようになりました。これらのアカウントは、ローカル システム アカウントよりも特権が少ないので、セキュリティの脅威が少なくなります。
しかし、自動更新、Computer Browser、Messenger、Windows インストーラ サービスなど、まだ多くのサービスがローカル システムでログオンします。ただし、そうでないサービスもあります。たとえば、Alerter サービスは Windows 2000 ではローカル システム アカウントを使用していましたが、Windows Server 2003 では Local Service アカウントを使用します。DNS クライアントは Windows 2000 ではローカル システム アカウントを使用していましたが、Windows Server 2003 では Network Service アカウントを使用します。次の表では、Windows Server 2003 でローカル システム アカウントを使用しなくなったサービスと、それが現在使用しているサービス アカウントを示します。
**注 :** Windows Server 2003 オペレーティング システムで提供されるサービスが使用するアカウントを変更しないでください。変更すると深刻な問題の原因となり、重要なサービスが停止して正常に実行されなくなる可能性があります。たとえば、DNS クライアント サービスでは、DNS サーバーなどのネットワーク リソースにアクセスする必要があるため、Network Service アカウントを使用します。このサービスは、ネットワーク リソースを認証できない Local Service アカウントやその他のアカウントでは動作しません。
**表 2.2: Windows Server 2003 での新しいサービス アカウント設定**
| Alerter |
Local Service |
| Application Layer Gateway Service |
Local Service |
| Remote Registry |
Local Service |
| Smart Card |
Local Service |
| TCP/IP NetBIOS Helper |
Local Service |
| Telnet |
Local Service |
| Uninterruptible Power Supply |
Local Service |
| WebClient |
Local Service |
| Windows Image Acquisition (WIA) |
Local Service |
| Windows Time |
Local Service |
| WinHTTP Web Proxy Auto-Discovery Service |
Local Service |
| DHCP Client |
Network Service |
| Distributed Transaction Coordinator |
Network Service |
| DNS Client |
Network Service |
| License Logging |
Network Service |
| Performance Logs and Alerts |
Network Service |
| Remote Procedure Call (RPC) Locator |
Network Service |
[](#mainsection)[ページのトップへ](#mainsection)
### サービスのセキュリティを保護して実行するための原則
サービスのセキュリティを適切に保護するには、ネットワーク環境で使用可能なサービスの性質を理解し、サービスの使用を保護する手順を確立する必要があります。ここでは、サービスのセキュリティを保護する計画をたてるときに従う必要のある、次の 3 つの主要な原則を調べます。
- システムの理解
- 最小特権の原則の使用
- 必要最低限のサービスの原則の使用
これらの原則を IT セキュリティの手順に正しく組み込むことができれば、サービスのセキュリティを適切なレベルに保つのに有効です。
#### システムの理解
この推奨事項は当たり前に思えますが、多くの組織はすべてのコンピュータで実行する役割とサービスについて、完全には把握していません。
コンピュータのセキュリティが保護されているかどうかを把握するには、コンピュータで実行されているサービスとそのプロパティを理解する必要があります。この情報は、サーバーのセキュリティを維持するために不可欠です。すぐにリスクを評価できるように、コンピュータで実行するサービスとそのサービスのプロパティ設定の対応表を作成する価値があるかどうかを検討してください。このような表の作成は、最初は時間のかかる複雑な処理になる可能性がありますが、さまざまなサーバーの役割の "既知の適切な構成" のプロパティを把握しておくことは非常に重要なので、この取り組みには非常に価値があります。
サービスのプロパティと実行しているサービスの一覧の作成を支援するツールがいくつかあります。このようなツールの例を次に示します。
- **サービス コントローラ ツール (sc.exe)**: このコマンド ライン ツールは、Windows Server 2003 および Windows XP に含まれています。このツールでは、コマンド ラインからサービス コントロール マネージャ コンポーネントと通信してクエリを送信し、サービスのプロパティを設定できます。
- **Windows Management Instrumentation (WMI)**: これは、Windows Server 2003 および Windows XP オペレーティング システムに事前にインストールされているコンポーネントで、管理情報やエンタープライズ環境での制御を提供します。システム管理を行う管理者は、業界標準を使用することによって、WMI でクエリを送信し、デスクトップ コンピュータ、アプリケーション、ネットワーク、およびその他のエンタープライズ コンポーネントの情報を設定することができます。システム情報やサービス コンソールの依存コンポーネントなど、WMI 対応の管理ツールもいくつかあります。サービスの依存関係として、現在のサービスが依存しているサービスと、現在のサービスに依存しているサービスを識別します。システム管理者は、WMI スクリプトを使用して管理タスクを自動化することもできます。
- **Windows Management Instrumentation コマンド ライン (WMIC)**: WMI には、コマンド ライン ツールの WMIC が含まれています。WMIC では、クエリを送信し、Windows オペレーティング システムを実行するコンピュータをリモートで管理するための簡単なコマンド ライン インターフェイスを WMI に提供します。コマンド プロンプトで「wmic」と入力して、WMIC を呼び出します。たとえば、Server1 というサーバーのサービスの情報を取得するには、コマンド プロンプトで次のように入力します。
**wmic /output:c:\\services.htm /node:server1 service list full / format:htable**
コマンドの結果は、HTML (Hypertext Markup Language) の表形式で c:\\services.htm ファイルに出力されるので、これを Microsoft Internet Explorer を使用して調べます。サーバー名にスペースまたは特殊文字が含まれる場合は、wmic コマンドを実行するときに名前を引用符で囲みます。
**注 :** sclist.exe という別のコマンド ライン ツールも使用できます。このツールは、Windows 2000 Server リソース キットに含まれています。このツールでは、現在実行しているサービス、停止したサービス、またはローカル コンピュータとリモート コンピュータ上のすべてのサービスが表示されます。sclist.exe では、物理的に遠隔地にあるコンピュータ、またはサーバー ラック内などのモニタを接続していないコンピュータで実行されるサービスを特定できます。
#### 最小特権の原則の使用
最小特権の原則に従うことについては、ほとんどのセキュリティ関連のトレーニング コースやドキュメントで触れられています。これは単純な原則ですが、これを実施することによって、大幅にセキュリティが向上し、リスクが軽減されます。最小特権の原則とは、エンティティが作業を行うのに必要最低限のアクセス許可しか与えないことです。Active Directory では、ユーザー アカウントとコンピュータ アカウントの両方がセキュリティ プリンシパルです。つまり、Windows Server 2003 ではこの両方のアカウントにアクセス許可と特権を割り当てることができるので、この原則はユーザー アカウントとコンピュータ アカウントの両方に適用されます。
この原則がうまく機能する理由の 1 つは、この原則によってネットワーク リソースを査定し、潜在的なセキュリティ リスクを評価しなければならないためです。特定のコンピュータやユーザーに実際に必要なアクセス特権を調査し、必要な特権しか適用していないことを確認する必要があります。
サービスのセキュリティを保護して実行するには、最小特権のアプローチを使用してサービスを展開する必要があります。できる限り Local Service アカウントでサービスを実行し、アカウントがドメイン全体ではなく 1 台のコンピュータにしかアクセスできないようにします。ネットワーク アクセスを認証する必要があるサービスには Network Service アカウントを使用する必要があります。広範に実装する必要があるサービスはローカル システム アカウントで展開します。サービスをドメイン レベルの管理者アカウントで展開する必要があると判断した場合は、そのサービスを展開するサーバーを "セキュリティの高いサーバー" として扱い、ドメイン コントローラなど機密性の高い他のネットワーク リソースと同じ方法でそのサーバーを保護する必要があります。このトピックの詳細については、第 3 章「サービスのセキュリティを保護して実行する方法」の「ドメイン管理者という例外のためにセキュリティの高いサーバー グループを作成する」を参照してください。
マイクロソフトでは Windows Server 2003 を完全にテストし、主要なオペレーティング システム サービスが既に最小特権しかないアカウントで実行されることを確認しています。したがって、通常、これらのサービスを変更する必要はありません。Microsoft SQL Server™ や Microsoft Operations Manager のような他のサーバー製品のコンポーネントとして提供されるサービス、およびサードパーティのソフトウェア製造元が提供するサービスなど、オペレーティング システムの一部ではないサービスのセキュリティを保護することは重要です。
Windows Server 2003 のグループ ポリシーを使用して、1 台以上のコンピュータで実行できる特定のサービスを制御することができます。これを行うには、構成するコンピュータを含む組織単位のグループ ポリシー オブジェクトを開きます。Computer Configuration\\Windows Settings\\Security Settings\\System Services ノードを参照し、制御するサービスの \[プロパティ\] ページを開きます。\[プロパティ\] ダイアログ ボックスで、サービスのスタートアップ モード (\[自動\]、\[手動\]、または \[無効\]) を定義し、どのユーザー アカウントがそのサービスで特定の操作 (サービスの停止や開始など) を実行できるかを制御する、セキュリティのアクセス許可を設定します。
サービスの実行に使用するアカウントの種類を判断するときに考慮する点の詳細については、第 3 章「サービスのセキュリティを保護して実行する方法」の図 3.1 「サービス展開の最小特権の階層」を参照してください。
複数のコンピュータ間に最小特権の原則を実装するときは、「システムの理解」で説明した規則と組み合わせることで機能します。どのサービスが実際に実行されているかを把握していなければ、コンピュータで必要最低限の数のサービスしか実行されていないことを確認できません。管理スタッフはこれら 2 つの原則を組み合わせることで、コンピュータでどのサービスが実行されているか判断し、各サーバーで使用されているサービスの状態や資格証明を評価することができます。その後、最小特権で実行できるすべてのサービスを体系的に変更することができます。コンピュータを監視して、適切な変更管理の処理を行わないと、新しいサービスを追加できないことを確認します。
#### 必要最低限のサービスの原則の使用
必要最低限のサービスの原則とは、すべてのネットワーク デバイスで使用できるオペレーティング システムとネットワーク プロトコルは、ビジネス目標をサポートするのに必要なサービスとプロトコルしか実行しないことです。たとえば、サーバーが Web アプリケーションをまったくホストする必要がなければ、World Wide Web サービスを削除するか無効にします。多くのオペレーティング システムやプログラムの既定の構成では、一般的な使用シナリオに実際に必要な数よりも多くのサービスやプロトコルをインストールします。
新しいサーバーをセットアップする最善の方法は、システム管理者がオペレーティング システムに最低限必要なもの以外をすべてシャットダウンする手順を加えることです。たとえば、Windows Server 2003 以前の Windows オペレーティング システムでは、Alerter サービスや Messenger サービスを終了することがよく行われました。さらに、ネットワーク上でのサービスの正しい配置を確認します。たとえば、Routing and Remote Access サービスやインターネット インフォメーション サービス (IIS) では、ドメイン コントローラの脆弱性を増加するバックグラウンド サービスを実行しているので、ドメイン コントローラにはこれらのサービスを配置するべきではありません。マイクロソフトのベスト プラクティスでは、ドメイン コントローラとして正常に機能するために必要なサービス以外の追加のサービスはドメイン コントローラで実行しないことをお勧めします。
Windows Server 2003 と Windows XP でサービスのセキュリティを保護することに関する詳細については、次のガイドを参照してください。
- [Windows Server 2003 セキュリティ ガイド](https://technet.microsoft.com/ja-jp/library/cc163140)
- [Windows XP セキュリティ ガイド](https://www.microsoft.com/japan/technet/security/prodtech/windowsxp/secwinxp/xpsgch01.mspx)
- [脅威とその対策ガイド](https://technet.microsoft.com/ja-jp/library/cc163024)
[](#mainsection)[ページのトップへ](#mainsection)
##### 目次
- [概要](https://technet.microsoft.com/ja-jp/library/551a769e-d7c1-41c2-8c2e-301350aedfbb(v=TechNet.10))
- [第 1 章 - はじめに](https://technet.microsoft.com/ja-jp/library/c9cfbe4a-25b8-4c72-a605-589bcfa92b29(v=TechNet.10))
- 第 2 章 - サービスのセキュリティを保護して実行するためのアプローチ
- [第 3 章 - サービスのセキュリティを保護して実行する方法](https://technet.microsoft.com/ja-jp/library/2959b144-bcb1-4467-a469-33cdb957485c(v=TechNet.10))
- [第 4 章 - まとめ](https://technet.microsoft.com/ja-jp/library/f6487e31-14a4-41a8-8203-cbcf5860da29(v=TechNet.10))
- [謝辞](https://technet.microsoft.com/ja-jp/library/a51d9e63-b73d-4884-8248-a0379210e7b9(v=TechNet.10))
[](#mainsection)[ページのトップへ](#mainsection)
.gif){kind=link}