Network Security Options

[Previous] [Next]

Now that we have an overview of how to get from the client to the server, it's a great time to start drilling down into the details of SQL Server security. The most logical place to start is the network. By default, everything except the user ID and password go across the network in cleartext. If you're concerned about security, and you must be to be reading this book, you'll probably want some way to encrypt the data flowing across your network. You can enable network encryption for all network traffic from the client computer to the server by using IPSec in Windows 2000. However, if you're encrypting only SQL Server traffic, you should use the mechanisms provided with SQL Server.

The Multi-Protocol Network Library

The Multi-Protocol network library uses Windows remote procedure call (RPC) support to communicate between the client and the server. However, what it does that's interesting from a security perspective is allow you to encrypt your data traffic to or from SQL Server.

To enable encryption at the server, you can check Enable Multi-Protocol Encryption in the server network utility or, when performing a custom setup, check the Enable Encryption option. Or you can create the key RPCNetlib in your Registry at HKEY_LOCAL_MACHINE/Software/Microsoft/MSSQLServer/MSSQLServer/Client and then add a value named Security of type Reg_Sz and set its string to Encrypt.

To enable encryption on the client side, edit the Registry on the client and add the same key just described, with the same value.

Note that the Multi-Protocol network library is supported to connect only to default instances of Microsoft SQL Server. It's being replaced with a new mechanism for enforcing network-level security for SQL Server: the Super Socket network library in SQL Server 2000.

The Super Socket Network Library

SQL Server 2000 introduces the Super Socket network library in an attempt to simplify how clients communicate with SQL Server. Essentially, SQL Server 2000 will communicate over TCP/IP sockets or named pipes, and the client can use either interface. However, from a security perspective, SQL Server 2000 offers something a bit more exciting: encryption of all network traffic, regardless of the network library being used under the covers.

If your server has a certificate that the client trusts, the network libraries will authenticate the server and negotiate an SSL/TLS connection between the client and the server. If you've set the client network utility option Enable Protocol Encryption, the client will attempt to use SSL/TLS. If it fails—because the server doesn't have a certificate, for instance—you won't be able to connect to the server.

On the server side, during setup there's an option to enforce encryption, and the same option exists in the server network utility: Require Protocol Encryption. If this option is set, all network traffic with that instance of SQL Server will be encrypted. If a client attempts to connect and the SSL/TLS handshake fails, the client will not be able to log in to SQL Server.

For databases handling sensitive data, you'll most likely want to enforce encryption of your data traffic. Good examples of such information include payroll, human resources, and medical data.



Designing Secure Web-Based Applications for Microsoft Windows 2000 with CDROM
Designing Secure Web-Based Applications for Microsoft Windows 2000 with CDROM
ISBN: N/A
EAN: N/A
Year: 1999
Pages: 138

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net