Microsoft's Trustworthy Computing initiative is so broad in scope that it's tantamount to calling the Internet an initiative. However, the important tenets of Trustworthy Computing—fondly called S3 plus C—are core to SQL Server 2005's security model. S3 plus C stands for secure by design, secure by default, secure in deployment, and communication. Let's look at how SQL Server 2005 (formerly code-named Yukon) implements these pillars of Trustworthy Computing.
Secure by design. One of the hard lessons customers and software vendors have learned over the past few years is that hackers are crafty. They look everywhere for any kind of vulnerability to exploit. Secure by design means reducing the surface area of vulnerabilities by eliminating them before the product ships. The key engineering goal for the SQL Server development team is to provide a product that can't be compromised. This pillar ties closely into the next one because the first way to be more secure is to create the smallest footprint possible by choosing secure configuration options—that is, to be secure by default.
Secure by default. The goal of the secure-by-default tenet is that when administrators choose the default installation options, they install SQL Server in a secure state. In SQL Server 2000 and earlier releases, SQL Server turned on all the server's functionality upon installation. For SQL Server 2005, a new "off by default" initiative is under way as part of the beta program. If a function, port, or service is off, it can't be hacked. When you install SQL Server 2005, you'll be putting bits down on the server; you won't be opening ports or adding services that start automatically behind the scenes.
In addition, many administrators grant permissions today through fixed roles within the server, leading some logins and users to receive more permissions than they need to perform their jobs. SQL Server 2005's new security model revolves around the principle of least privileges. In other words, if your application doesn't need system administration (sa) permissions, it won't have them. SQL Server 2005 also introduces multiple scopes and permissions to help security administrators effectively and efficiently handle permissions without violating the principle of least privileges.The new security model essentially breaks the world into principals (those who can access database objects) and entities (known in "security speak" as the secureables). Principals—such as individuals, groups, applications, and processes—can request access to secureables. SQL Server 2005's security model manages and verifies permissions, either granting or denying access at various scopes (server, database, schema, individual table, or a subset of a table, such as a column). With this new security model, DBAs have fine-grain control of database objects. For example, with SQL Server 2000, anyone who can connect to a database server through Enterprise Manager can see all the objects in the server. With SQL Server 2005, users will see only the objects for which they have permissions.
The rule of least privileges applies to familiar technologies such as SQL Agent and replication as well as to new technologies such as SQL Server Service Broker and XML Web services. For technologies such as XML Web services, mechanisms are also in place to prevent malicious XML injections and a host of other potentially dangerous scenarios.
So, SQL Server 2005's new security model reduces the built-in surface area of attack by turning off by default features that you don't use. And the new permissions model lets you better manage permissions, principals, and entities. Taking advantage of these features in SQL Server 2005 will let you rest easier after you upgrade. However, upgrading will likely mean changing your application-development practices, which brings us to the next pillar.
Secure in deployment. Microsoft has buttressed the security of all SQL Server components' authentication and authorization mechanisms. In SQL Server 2005, you'll see the benefit of these changes in more secure data transmission and tighter cross-platform integration. You'll be able to associate users and processes with certificates. And in response to your requests, Microsoft has substantially enhanced impersonation mechanisms, letting executable objects such as procedures, triggers, and functions run within a specified security context.
The market over the past few years has pushed Microsoft to add encryption in SQL Server. Frankly, providing encryption isn't difficult; managing encryption is the challenge. SQL Server 2005, however, provides mechanisms for encrypting and decrypting data and provides a rich infrastructure for key management, recovery, and generation.
Communication. The last pillar—communication—is probably the most important. Communication about service packs, patches, and the process and problems associated with them is central to the success of SQL Server customers. Microsoft is working with customers to take the pain out of product maintenance, including producing best-practices guidance that will help developers and DBAs build and run the most secure applications possible. Remember that communication is a two-way street: Make sure you grab SQL Server 2005 Beta 2 this summer, and let me know what you think of its security features.
