Communication Channel Considerations

Sensitive application data and authentication credentials that are sent to and from the application server should be encrypted to provide privacy and integrity. This mitigates the risk associated with eavesdropping and tampering.

Encrypting network traffic addresses the network eavesdropping and tampering threats. If you consider this threat to be negligible in your environment for example, because your application is located in a closed and physically secured network then you do not need to encrypt the traffic. If network eavesdropping is a concern, then you can use SSL, which provides a secure communication channel at the application layer, or IPSec, which provides a transport-level solution. IPSec encrypts all IP traffic that flows between two servers, while SSL allows each application to choose whether or not to provide an encrypted communication channel.

Enterprise Services

Enterprise Services (or COM+) applications communicate over the network using DCOM over RPC. RPC uses port 135, which provides endpoint mapping services to allow clients to negotiate parameters, including the communication port, which by default is dynamically assigned.

The Enterprise Service channel can be secured in one of two ways:

• RPC Encryption

  You can configure an Enterprise Services application for RPC Packet Privacy authentication. In addition to authentication, this provides encryption for every data packet sent to and from the Enterprise Services application.

• IPSec

  You can use an IPSec policy between the Web server and the application server to encrypt the communication channel.

.NET Remoting

Two possible implementation models exist for applications that use .NET Remoting:

• HTTP channel over port 80

  This model uses ASP.NET as the hosting service.

• TCP channel over any port

  In this model, the application is hosted inside a custom executable, usually a Windows service.

Depending on the performance and security requirements of the application, you can use one of two methods to secure the Remoting channel.

• Use SSL with the HTTPChannel.

  If you host in ASP.NET, you can take advantage of the built-in HTTPS functionality provided by IIS. HTTPS provides authentication and secure data communication.

• Use IPSec with the TCPChannel .

  With the TCP channel, you can use an IPSec policy to provide transport-layer encryption for all IP data. Note that if you use the TCP channel, you must provide your own authentication mechanism. For more information, see Chapter 13, "Building Secure Remoted Components."

Web Services

Web services are hosted by ASP.NET and IIS, and the services use the HTTP protocol for communication over the network.

SSL or IPSec can be used to secure the communication channel. Alternatively, encryption can be handled at the application layer by encrypting the message payload or the sensitive parts of the payload. To do this using open standards, use the Web Services Enhancements (WSE) download available for Web services. For more information, see Chapter 12, "Building Secure Web Services."

SQL Server

The application server communicates with SQL Server using TCP port 1433 by default. Unless otherwise configured, UDP port 1434 is also used for negotiation.

To secure the channel from the application server to SQL Server, use IPSec or SSL. SSL requires a server certificate to be installed on the database server.

For more information on using SSL with SQL Server, see Microsoft Knowledge Base article 276553, "How To: Enable SSL Encryption for SQL Server 2000 with Certificate Server."