blog

エンタープライズWindows環境でWebサービスを保護する5つのステップ

この記事では、Webサービスが安全に実行されるように、CAS、認証、なりすまし、認可などの側面をさまざまな設定ファイルで構成する方法について説明します。...

Dec 17, 2015 · 6 min. read
シェア

中堅から大企業の大部分は、エンタープライズ Web サービスとアプリケーションを構築するために、.Net アーキテクチャだけでなく Windows Server も使用しているため、Web サービスと Web アプリケーションは、ASP.NET と IIS によって管理されています。Web サービスと Web アプリケーションのセキュリティ確保は、プログラミングよりもむしろ、環境設定の問題です。例えば、SSL/TLSを使用して暗号化によって機密性を確保することは、それを実装する最良の方法です。アプリケーションに対してこれを有効にする簡単な方法は、IIS を適切に設定し、アクセスに https 接頭辞を持つ RL を使用することです。

ASP.NETセキュリティの設定には、主にXML文書の階層的なコレクションの編集が含まれます。このツリーの最上位はmachine.configで、このマシン上で実行されるすべてのASP.NETアプリケーションのグローバル設定が行われます。グローバル設定ファイルの下には、個々のASP.NETアプリケーションの設定を含むweb.configファイルがあります。この記事では、CAS、認証、なりすまし、認可などの側面をこれらのファイルでどのように設定し、Web サービスが安全に実行されるようにするかについて説明します。

1、ASP.NET用にCASを設定します。

CASは、主に悪意のあるモバイルコードからシステムクライアントを保護する方法として使用されていますが、サーバー側のWebサービスやWebアプリケーションのデプロイメントにも関連性があります。この場合、CASは、あるエンティティが所有するアプリケーションが、他のエンティティが所有するアプリケーションやサーバオペレーティングシステムによって妨害されるリスクを低減するのに役立ちます。

ただし、次の点に注意してください。デフォルトでは、CASポリシーはASP.NETアプリケーションにアセンブリの完全なセットを付与します。なぜなら、アプリケーションはローカルマシンから実行されるからです。明らかに、アプリケーションを構成するときにこれを修正する必要があります。.NET Frameworkは、ASP.NETアプリケーションに付与される特権を決定するために使用できる、完全、高、中、低、および最小という多くの異なる信頼レベルを定義しています。web_hightrust.config、web_mediumtrust.configなどの設定ファイルで指定されるこれらのポリシーの最初のものを除いて、他のすべてのポリシーは.NET FrameworkルートディレクトリのConfigurationサブディレクトリにあります。特定のASP.NETアプリケーションに中程度の信頼レベルを許可するには、そのweb.configファイルに次の構造を指定する必要があります:

<configuration>
<system.web>
<trust level="Medium"/>
</system.web>
</configuration>

2.最小特権での実行

個々の ASP.NET リクエストを処理する「ワーカープロセス」は、Windows 環境で ASPNET というアカウントで実行されます。この特定のアカウントは制限された Windows 特権を持ち、この損害を制御するために ASP.NET アプリケーションに譲る必要があります。しかし、作業プロセスを IIS と同じアカウント(SYSTEM アカウント)で実行することは可能です。これを実現したい場合、記述するmachine.configファイルは次のようにします:

<configuration>
<processModel userName="System" password="AutoGenerate"/>
</configuration>

このような変更を有効にするには、IIS管理サービスとWWW公開サービスを再起動する必要があります。

このようにする理由の1つは、ASP.NETコードがなりすまし目的でWindowsユーザーからアクセストークンを取得するために、Win32 APIからLogonUserを呼び出せるようにすることかもしれません。しかし、これは最小特権という基本的なセキュリティ原則に違反するだけでなく、攻撃が成功した場合の損害を大幅に増加させます。しかし、これは最小特権という基本的なセキュリティ原則に違反します。

3.識別

ASP.NETには、None、Windows、Forms、Passportの4種類の認証があり、それぞれアプリケーションのルートファイルであるweb.configで設定します。例えば、ASP.NET 認証を完全に無効にする(ユーザがログインする必要のない公開 Web サイトに適している)には、次のような設定ファイルが必要です:

<configuration>
<system.web>
<authentication mode="None"/>
</system.web>
</configuration>

IIS認証とASP.NET認証の相互作用に留意する必要があります。希望する結果を得るには、両方を正しく設定する必要があります。通常、IISとASP.NETの両方でWindows認証モードを使用し、IISでは匿名モード、ASP.NETではNone、Forms、Passportのいずれかを使用します。

IISとASP.NETの両方でWindows認証を使用する利点は、パスワードをネットワーク経由で送信する必要がなく、クライアントアプリケーションがIISに現在ログインしているユーザーの身元に関する情報を提供し、その情報をASP.NETアプリケーションに転送できることです。このアプローチの欠点は、クライアント側とサーバー側の両方でWindowsオペレーティングシステムに依存していることです。フォーム形式の認証は、インターネットベースのシステムにより適切なアプローチですが、この場合、ユーザーから提供された認証情報が暗号化されることを保証するためにSSL/TLSを使用することが非常に必要です。

4.偽造

Windows Identityが選択されているかどうかにかかわらず、ASP.NET Identityは、ASP.NETアプリケーションを実行するユーザー環境を指定しません。ASPNETアカウントだけでなく、任意のアカウントの環境でアプリケーションを実行したい場合は、IDを偽装する必要があります。

要求されたユーザは、IISによって有効なWindowsユーザとしてライセンスされていることが前提となります:

<configuration>
<system.web>
<identity impersonate="true"/>
</system.web>
</configuration>

これにより、ASP.NETアプリケーションはリクエストを行うユーザーになりすます。ただし、IISが匿名認証に設定されている場合、ASP.NETアプリケーションは匿名アクセス用に設定されているIISのユーザーアカウントになりすまします。

ASP.NETアプリケーションで特定のユーザーになりすますのは簡単です:

<configuration>
<system.web>
<identity impersonate="true" userName="Foo\bar" password="baz"/>
</system.web>
</configuration>

ここでの明らかな危険は、web.config にプレーンテキストでユーザ認証情報が存在することです。この危険性を回避するには、暗号化されたユーザ認証情報をレジストリに保存し、web.config 要素から参照します。

<identity impersonate="true"
  userName="registry:HKLM\Software\MyApp\AspNet,Name",
  password="registry:HKLM\Software\MyApp\AspNet,Password"/>

このユーティリティ aspnet_setreg.exe は、ユーザー認証情報を暗号化し、暗号化されたユーザー認証情報をレジストリに保存するために使用する必要があります。

5.認可

ASP.NETでWindows認証を適用すると、指定されたリソースにアクセスするために、認証されたユーザーは必要なNTFS権限を持っている必要があります。これはファイル認証として知られています。ASP.NETは、URL認証として知られている、より柔軟な認証タイプをサポートしています。ファイル認証とは異なり、これはアプリケーションのweb.configファイルを通して設定されます。これは主にASP.NET認証でアプリケーションを割り当てることに基づいており、ライセンスされたWindowsアカウントの権限に基づいていません。単純な URL 認証設定の例を以下に示します:

<configuration>
<authorization>
<allow verbs="GET" users="Fred,Joe"/>
<deny verbs="POST" users="Fred,Joe"/>
<allow roles="Developers"/>
<deny users="*"/>
</authorization>
</configuration>

この例では、ユーザ Fred と Joe が web.config ファイルで管理されたウェブサイト内の任意のリソースに対する HTTP GET リクエストをアプリケーションに送ることができます。しかし、HTTP POST リクエストはそれらのリソースへのアクセスを拒否します。開発者ロールの人はサイトへの無制限のアクセスを許可されますが、他のすべてのユーザはリソースへのアクセスを拒否されます。ASP.NETが使用するのは最初にマッチした要素なので、これらの要素の順番は重要です。デフォルトではmachine.configファイルにそのような設定が含まれているため、最後の明確化は通常サイトをロックするために必要です:

<authorization>
<allow users="*"/>
</authorization>
Read next

HFCとPON技術の結婚

HFC双方向光ネットワークの特性と組み合わせることで、双方向HFC光ネットワークの設計を構築するために提案されたPONネットワーク技術。スキームダウンストリームはまだ元の光トランシーバを使用して、ダウンストリームは、ファイバを占有し、サービスのすべての光ノードが戻ってファイバを占有します。

Dec 13, 2015 · 3 min read