SQL Server 2005 Security - Part 3 Encryption

After discussing authentication and authorization behavior of SQL Server 2005 Beta 2 in the previous two articles of this series, it is time to look into other security-related changes. In particular, we will focus on the freshly introduced native database encryption capabilities. While some encryption functionality existed in the previous versions (e.g. involving column encryption APIs within User Defined Functions or PWDENCRYPT password one-way hash function), it was relatively limited and rarely used. SQL Server 2005 provides significant improvements in this area.

SQL Server 2005 Security - Part 2 Authorization

Following the discussion of new or enhanced authentication-related functionality in SQL Server 2005 Beta 2 in our previous article, we are shifting our focus to authorization features, which determine the level of access rights once the user's logon process is successfully completed. Among topics that will be covered here, are separation of user and schema, modifiable context of module execution, increased permission granularity, and improved catalog security.

Who owns temporary objects created in a procedure?

The Case of the Stolen Laptop: Mitigating the Threats of Equipment The

The fear of having laptops stolen is a huge worry for all organizations. Maybe it’s even happened to you (I hope not!). The solution is simple, really -- don’t let your laptop get stolen. (I can hear you laughing now.) Keep the thing with you at all times, or leave it in your hotel room when you don’t want to carry it around. Yes, everyone has heard the warnings about hotel room theft, but I’ve never had something stolen from a hotel room and I spend well over 200 nights a year in hotels. (If you travel to a location where the general population has kleptomaniac tendencies, stay in hotels that offer safes in the room.) You’re far more likely to leave your laptop or PDA or smart phone or USB drive lying on the seat in a taxi or on the counter at a bar.

SQL Server 2005 brings us a number of...

What would this statement do in SQL Server...

SQL Server 2005 Part 1 - Security (Authentication)

In this installment of our series covering new and improved functionality of SQL Server 2005 Beta 2, we will focus on the topic of security, which has been becoming increasingly prominent among the issues on every database and system administrator's agenda. A new approach to software development started with the Trustworthy Computing initiative launched in early 2002, necessitated by the growing number of exploits directed at the Microsoft operating system and applications, resulted in a "secure by default" product with highly customizable security features further increasing the degree of protection. We will start with the features related to authentication (the process of identifying logins connecting to the SQL Server and users accessing databases), and continue with authorization (determining the level of permissions granted once the initial connection is established) and encryption in the future articles. In particular, we will cover here, password policy implementation and management as

DATA PIRACY: THE THREAT FROM WITHIN

Databases are being stolen. Customer data, credit card data, taxpayer data - they're all vulnerable. Scary? Yes - but wait, there's more. It's not just "their" data that's vulnerable - it's ours too!

Removing the Builtin Administrators - Some Pitfalls to Avoid

The SQL Server 2000 security model is not the best one of all the RDBMS platforms and requires some work to secure properly. One of the practices that is recommended is removing the builtin/administrators group from accessing the SQL Server. New author Kathi Kellenberger shows us some of the pitfalls she encountered when removing this group from her servers.

Securing Your Microsoft SQL Server Databases in an Enterprise Environm

If you are running Microsoft SQL Server databases to support critical enterprise applications, you are part of a growing trend.