|
|
Internet Protocol Security (IPSec) can be used to secure the data sent between two computers, such as an application server and a database server. IPSec is completely transparent to applications because encryption, integrity, and authentication services are implemented at the transport level. Applications continue to communicate with one another in the normal manner using TCP and UDP ports.
Using IPSec you can:
Provide message confidentiality by encrypting all of the data sent between two computers.
Provide message integrity between two computers (without encrypting data).
Provide mutual authentication between two computers. For example, you can help secure a database server by establishing a policy that permits requests only from a specific client computer (for example, an application or Web server).
Restrict which computers can communicate with one another. You can also restrict communication to specific IP protocols and TCP/UDP ports.
This How To shows you how to secure the communication channel between an application server and a database server running SQL Server 2000. The application server uses the recommended TCP/IP client network library to connect to SQL Server and uses the default SQL Server TCP port 1433. The configuration is shown in Figure 1 on the next page.
This How To describes how to use a simple IPSec policy to enforce the following:
Allow communications with SQL Server only from the application server using TCP through port 1433.
Drop all other IP packets, including ICMP (ping).
Encrypt all data sent between the two computers to guarantee confidentiality.
The advantages of this approach are:
Data confidentiality is provided for all data sent between the two computers.
The attach surface on SQL Server is significantly reduced. The only remaining points of attack are to interactively log on to the database server or to gain control of the application server and try to attack SQL Server via TCP port 1433.
The IPSec policy is extremely simple to define and implement.
This particular policy suffers from the following drawbacks:
SQL Server cannot communicate with domain controllers and as a result:
Group policy cannot be applied (the database server should be a standalone server).
Windows authentication between the application server and database server requires synchronized local accounts (with the same user name and password) on both computers.
You cannot use more robust methods of applying IPSec (Windows 2000 default / Kerberos).
SQL Server will not be able to communicate with other computers, including DNS servers.
The approach presented in this How To uses pre-shared key authentication, which is not recommended for production scenarios. Production systems should use certificates or Windows 2000 domain authentication. IPSec policies that use pre-shared secrets are suitable for use in development or test environments only.
Both computers must have static IP addresses.
|
|
