投稿者: Saad Ladki
外部からのアクセスの縮小
IIS 6.0 では、"既定ロックダウン" アプローチが導入されました。 これはそれまでの IIS バージョンからの大幅な移行です。以前は、既定でほぼすべての機能が最初からインストールされて有効であり、Web サーバーの機能性は高いものの露出が最大の状態になっていました。 IIS 6.0 では、いくつかの機能が既定インストールから削除され、他の多くの機能はインストールされるものの既定インストールでは無効になっています。
IIS 7.0 以降では、"既定最小インストール" アプローチを導入することで、このアプローチを次のステップに進めます。 IIS には、以前のバージョンの IIS としてインストール可能なコンポーネントの数 5 times 以上にコンポーネント化された、完全にモジュール化された Web サーバーが含まれています。 IIS では、最小限のわずかなコンポーネントのみがインストールされ、有効になります。 この主な利点はいくつかあります。
- インストールされるコンポーネントの数が少ないほど、攻撃者から狙われる潜在的な領域が小さくなる
- インストールされるコンポーネントの数が少ないほど、管理、修正プログラムの適用、保守が軽減される
- メモリ内のコンポーネント数が少ないほど、パフォーマンス、スケーラビリティ、信頼性が向上する
セキュリティ管理の簡素化
IIS によって、セキュリティ管理のいくつかの重要な簡略化が実現し、セキュリティ保護の確保と維持が容易になります。 これらの管理の改善点は次のとおりです。
- リッチ委任管理サポート。構成および管理タスクをスコープ指定して、簡単かつ完全な方法で、管理者以外に委任することができます。
- 統合された認証と認可の管理。フォーム認証や URLAuthorization を含む、すべての種類の認証と認可をあらゆる種類のコンテンツに対して 1 か所で管理できます。
- Web サーバー専用の組み込みのユーザー アカウントおよびグループ アカウント。コンピューター間で共通のセキュリティ識別子 (SID) を使用できるようになり、NTFS ACL の管理が簡素化され、アプリケーション プールのサンドボックス化と ID 管理が簡素化されます。
セキュリティの強化
IIS には、いくつかの新しいセキュリティ機能も用意されており、要求のフィルタリングなど、Web サーバーのセキュリティ機能が強化されます。 IIS に新しく組み込まれた要求のフィルタリングは、動詞、ファイル拡張子、サイズ、名前空間、シーケンスに基づいて、要求をその場でフィルター処理できます。 この機能の多くは、以前に URLScan (Web ダウンロードとして入手可能な ISAPI フィルター) で提供されていましたが、組み込み IIS モジュールとして使用できるようになりました。
リッチ委任インフラストラクチャ
以前は、IIS で管理者以外のユーザーに管理タスクの委任を設定することは非常に困難でした。
IIS 5.0 では管理ツールを使用して Web オペレーター (https://www.microsoft.com/windows2000/en/server/iis/default.asp?url=/windows2000/en/server/iis/htm/core/iiwbsop.htm
) を指定できました。また、IIS 6.0 では IIS チームによって、このシナリオに対処するメタベース ACL の変更が導入されました。
これらの各ソリューションには、IIS チームが学ぶことができる利点と欠点がありました。 チームは、お客様からのフィードバックを使用し、新たに IIS リッチ委任モデルを開発しました。 新しいアーキテクチャで、管理者は次のことができます。
- Windows プリンシパルと Windows 以外のプリンシパルの両方を使用して委任管理インフラストラクチャを設定します。
- サーバー、サイト、アプリケーションのスコープで設定を構成します。 サイトとアプリケーションの管理者は、サイトとアプリケーションを管理するためにボックス管理者になる必要はありません
IIS が追加設定なしでセキュリティで保護されるように、委任は既定でロックダウンされています。 これが何を意味するのかを理解するために、このセクションでは以下について説明します。
- セキュリティで保護された IIS のロックに関する既定値
- 既定の IIS アクセス許可を使用して、セキュリティで保護された委任が追加設定なしで有効になる方法
当初からの目標は、IIS 7.0 以降で前身の IIS 6.0 と同様のセキュリティ保護を実現するすることでした。 IIS 6.0 には、メタベースと呼ばれる 1 つのプライマリ構成ファイルがありました。しかしながら、メタベース ACL を使用した委任シナリオの設定はあまり一般的でも簡単でもありませんでした。
IIS 7.0 以降の委任モデルでは、製品チームは、applicationHost.config (メタベースに代わるもの) をできるだけ厳しくロックダウンできるようにする必要がありました。 同時にチームが行ったのは、委任を設定する管理者が面倒な手間をかけずにごく簡単に使用できるものにすることです。
セクションが "ロック" されているのは、アプリケーションまたはサイト管理者がセクションを再定義できないことを意味します。 セクションが "ロック解除" されているのは、サイトまたはアプリケーション管理者にセクションの変更が許可されることを意味します。 前述のドキュメントでは、セキュリティ、パフォーマンス、信頼性の観点から各セクションについて説明し、複数のセクションの中で特定のセクションのロック解除を選択する理由を示しています。 環境の要件に基づいて、セクションをロック解除するか、さらにロックダウンするかを選択できます。
既定の IIS アクセス許可によりセキュリティで保護された委任をすぐに有効にする方法
これらのセクションでは、Vista およびサーバーの IIS 上で、委任とアクセス許可が互いにどのように関連するかという概要について説明します。 また、管理者以外のユーザー (Windows ID と Windows 以外の ID の両方) を簡単に設定して、既定のアクセス許可を変更せずにサイトとアプリケーションの両方を管理する方法も示します。
まず、Vista クライアントについて調べ、次にサーバーを確認します。 何が起きるかを明確に理解できるように、内容の重要なポイントに関連して詳しい段階的な説明を提供します。
Vista クライアント
Vista クライアントの設計は 2 つの主な目標に基づいていました。
- UI を使用したクライアントへの委任は、Windows Vista でサポートされている機能ではありません。
- 構成ファイルを介した委任は、LUA が有効になっている、管理者以外の Windows ユーザー アカウントで完全にサポートされます。 管理者アカウントを使用する場合は、正常に機能するために LUA を無効にする必要があり、これは推奨されません。
ここで、このセクションでは、2 番目のポイントについて説明し、管理者以外の Windows アカウントを使用して簡単に委任を設定する方法を示します。
管理者以外の Windows アカウントを使用した委任
これは、管理者が、次のユーザーが存在するシステムに委任モデルを実装しようとする場合の一般的なシナリオです。
ローカル アカウント データベースまたは Active Directory に存在する Windows アカウント。
- 管理者グループに含まれない
- ユーザー グループに含まれる
Windows Server® 2008
Windows Server 2008 では以下が提供されることで、委任が次のレベルに進化します。
- サーバー上のすべてのクライアント委任シナリオの完全なサポート
- UI を介した委任の完全なサポート (Windows 以外のプリンシパルの使用を含む)
セキュリティで保護されたアクセス許可と 非 Windows プリンシパルの使用による委任を UI がどのようにサポートするかを理解できるように、以下の概要について段階的に詳しく説明します。
- 管理者以外の Windows アカウントと UI を使用した委任
- 非 Windows アカウントと UI を使用した委任
統合セキュリティ アーキテクチャ
ASP.NET アプリケーションをサポートしていた以前のバージョンの IIS には、アプリケーション開発者向けのエンド ツー エンド ソリューションを提供する 2 つのリッチ セキュリティ アーキテクチャがありました。 最初のモデルは IIS によって提供され、2 つ目は ASP.NET によって提供されました。
IIS チームは、IIS 7.0 を再設計する際に、その機会を利用してこれら 2 つのモデルを統合しました。 現在、IIS 7.0 以降には、次に対応する 1 つのパイプラインがあります。
- ローカル アカウント データベースまたは Active Directory に存在する Windows プリンシパルを完全にサポートする (以前と同様)
- 非 Windows プリンシパルを完全にサポートする
- すべての認証と認可を行う 1 つの場所を提供する
IIS 7.0 以降のアーキテクチャのその他の利点として、ASP.NET 2.0 で提供されるリッチ メンバーシップ システムを利用できるようになった点があります。 新しいメンバーシップ システムを使用すると、ASP.NET 2.0 でサポートされるすべて (たとえば SQL) をサポートできます。または、カスタム プロバイダーを作成して IIS 7.0 以降で "単に動作" させることができます。
Windows プリンシパルを完全にサポートする
以前のバージョンの IIS と同様に、次のような以前の認証スキームはすべて IIS 7.0 以降で引き続き使用できます。
- Windows 認証
- 匿名認証
- 基本認証
- ダイジェスト認証
- 証明書の認証
これらの種類の認証からトークンが作成された場合、追加の構成なしで、IIS アプリケーションでも ASP.NET アプリケーションでも引き続きトークンを使用できます。
非 Windows プリンシパルを完全にサポートする
フォーム認証機能は IIS 7.0 で導入されました。 以前は、これは ASP.NET アプリケーションでのみ使用されていましたが、IIS 7.0 以降のアーキテクチャでは、前のセクションで説明した他の認証スキームと同様にフォーム認証を使用して非 Windows ID を認証できます。
すべての認証と認可を行う 1 つの場所を提供する
IIS 管理ツールと構成ファイルのどちらを使用する場合でも、すべての認証および認可ポリシー (ASP.NET と IIS 7.0 以降の両方) は、<system.webServer>
グループ内の <authentication> セクションと <authorization> セクションそれぞれで構成できることに注意してください。
これで、管理者が規則を定義したり、サーバー上で何が起こっているかを確認したりすることが簡単になりました。
学習を開始する
IIS 7.0 以降のセキュリティ機能の使用を開始する