次のセクションでは、Windows Communication Foundation (WCF) を使用してセキュリティで保護されたアプリケーションを作成するときに考慮するベスト プラクティスを示します。 セキュリティの詳細については、 セキュリティに関する考慮事項、 データのセキュリティに関する考慮事項、および メタデータに関するセキュリティに関する考慮事項を参照してください。
SPN を使用して Windows 認証を実行するサービスを特定する
サービスは、ユーザー プリンシパル名 (UPN) またはサービス プリンシパル名 (SPN) で識別できます。 ネットワーク サービスなどのマシン アカウントで実行されているサービスには、実行しているマシンに対応する SPN ID があります。 ユーザー アカウントで実行されているサービスには、実行しているユーザーに対応する UPN ID がありますが、 setspn ツールを使用してユーザー アカウントに SPN を割り当てることができます。 SPN を介して識別できるようにサービスを構成し、その SPN を使用するようにサービスに接続するクライアントを構成すると、特定の攻撃がより困難になる可能性があります。 このガイダンスは、Kerberos または SSPI ネゴシエーションを使用するバインディングに適用されます。 SSPI が NTLM にフォールバックする場合でも、クライアントは SPN を指定する必要があります。
WSDL でサービス ID を確認する
WS-SecurityPolicy を使用すると、サービスはメタデータ内の独自の ID に関する情報を公開できます。
svcutilまたはその他のメソッド (WsdlImporter など) を使用して取得すると、この ID 情報は WCF サービス エンドポイント アドレスの ID プロパティに変換されます。 これらのサービス ID が正しく、有効であることを確認しないクライアントは、サービス認証を効果的にバイパスします。 悪意のあるサービスは、WSDL で要求された ID を変更することで、このようなクライアントを悪用して資格情報の転送やその他の "中間者" 攻撃を実行する可能性があります。
NTLM ではなく X509 証明書を使用する
WCF には、ピアツーピア認証の 2 つのメカニズムが用意されています。X509 証明書 (ピア チャネルで使用) と Windows 認証。SSPI ネゴシエーションが Kerberos から NTLM にダウングレードされます。 1024 ビット以上のキー サイズを使用した証明書ベースの認証は、いくつかの理由から NTLM よりも優先されます。
相互認証の可用性、
より強力な暗号アルゴリズムの使用、および
転送された X509 資格情報を使用する方が難しくなります。
偽装後に常に元に戻す
クライアントの偽装を有効にする API を使用する場合は、必ず元の ID に戻してください。 たとえば、 WindowsIdentity と WindowsImpersonationContextを使用する場合は、次のコードに示すように、C# using ステートメントまたは Visual Basic Using ステートメントを使用します。
WindowsImpersonationContext クラスはIDisposable インターフェイスを実装するため、コードが using ブロックから離れると、共通言語ランタイム (CLR) は自動的に元の ID に戻ります。
WindowsIdentity identity = ServiceSecurityContext.Current.WindowsIdentity;
using (identity.Impersonate())
{
// Run code under the caller's identity.
}
Dim identity = ServiceSecurityContext.Current.WindowsIdentity
Using identity.Impersonate()
' Run code under the caller's identity.
End Using
必要に応じてのみ偽装する
WindowsIdentity クラスの Impersonate メソッドを使用すると、非常に制御されたスコープで偽装を使用できます。 これは、操作全体のスコープの偽装を可能にするOperationBehaviorAttributeのImpersonation プロパティを使用するのとは対照的です。 可能な限り、より正確な Impersonate メソッドを使用して偽装のスコープを制御します。
信頼できるソースからメタデータを取得する
メタデータのソースを信頼し、誰もメタデータを改ざんしていないことを確認してください。 HTTP プロトコルを使用して取得されたメタデータはクリア テキストで送信され、改ざんされる可能性があります。 サービスが HttpsGetEnabled プロパティと HttpsGetUrl プロパティを使用する場合は、サービス作成者から提供された URL を使用して、HTTPS プロトコルを使用してデータをダウンロードします。
セキュリティを使用してメタデータを公開する
サービスの公開されたメタデータの改ざんを防ぐには、トランスポートまたはメッセージ レベルのセキュリティでメタデータ交換エンドポイントをセキュリティで保護します。 詳細については、「 メタデータ エンドポイントの発行 」および「 方法: コードを使用してサービスのメタデータを発行する」を参照してください。
ローカル発行者の使用を確認する
特定のバインディングに対して発行者のアドレスとバインドが指定されている場合、そのバインディングを使用するエンドポイントにはローカル発行者は使用されません。 常にローカル発行者を使用することを想定しているクライアントは、そのようなバインディングを使用しないようにするか、発行者アドレスが null になるようにバインディングを変更する必要があります。
SAML トークン サイズクォータ
Security Assertions Markup Language (SAML) トークンがメッセージでシリアル化される場合(セキュリティ トークン サービス (STS) によって発行されたとき、またはクライアントが認証の一環としてサービスに提示する場合は、SAML トークンとその他のメッセージ部分に対応するために、メッセージ サイズの最大クォータが十分に大きい必要があります。 通常は、既定のメッセージ サイズ クォータで十分です。 ただし、数百の要求が含まれているために SAML トークンが大きい場合は、シリアル化されたトークンに対応するためにクォータを増やす必要があります。 クォータの詳細については、「 データのセキュリティに関する考慮事項」を参照してください。
カスタム バインドで SecurityBindingElement.IncludeTimestamp を True に設定する
カスタム バインドを作成するときは、 IncludeTimestamp を true に設定する必要があります。 それ以外の場合、 IncludeTimestamp が false に設定されていて、クライアントが X509 証明書などの非対称キーベースのトークンを使用している場合、メッセージは署名されません。