Better SQL Server Security - How to protect your database

I have a database that was created for a custom application. The application may be broken up into multiple tiers or not. All interaction with the data is done using stored procedures. My problem is that I want to constrain my end users to accessing and executing the stored procedures through the custom application and nothing else. That means the user should not be able to go applications like Excel and make a connection to the database and execute one of the stored procedures. And keep in mind my users must authenticate and be authorized in SQL Server using their Windows identity for security and auditing purposes.

I have read posts on the Internet saying that Logon Triggers are a great way to prevent people from connecting to databases using “unapproved” software applications. The application would specify a Application Name in its connection string (Application Name=MyCustomApplication). A logon trigger can be written and the app_name can be evaluated and only allow the applications you ever wanted to connect to the SQL Server, thus eliminating Excel. While this is all fine and good, this isn’t 100% foolproof. Rouge EXEs could spoof an application name that is on the good list of EXEs and circumvent the logon trigger’s purpose.

I have also read that using a loginless account is one way to prevent users from accessing a database directly using their Windows identity. For example, let’s assume you have stored procedures written and you grant the loginless account rights to execute the procs. As long as the EXECUTE AS ‘loginless account’ is executed prior to executing the procs, then this works pretty well. The end users don’t have rights themselves to execute the procedures, but as the loginless used for the impersonation does. The problem I have with this approach is that you are requiring your application code to execute that EXECUTE AS statement before anything else is executed. And because the EXECUTE AS is scoped for the session/module, each time the application were to execute a procedure, it would have to first call the EXECUTE AS and do so over the wire (problem if you aren’t using SSL).

I also read about using signed procedures. In this case a certificate user is granted access to the tables themselves. And then the stored procedures are signed with the same certificate. Then the end users are permissioned to the stored procedures. But I don’t see how it is relevant because it seems this is addressing the issue of where ownership chaining is not possible. The users would still have the ability to execute the procedures from any application they wanted to.

So my problem is there is no good surefire way of allowing a Windows authenticated user to a database and only to the database if the user is using the application the database is intended for. There just seems to be no good way to handle this. There are of course things like Application Roles, but if you have spent any time with them, you know they are pretty much worthless in an enterprise class application. It seems in SQL 2005, Microsoft started to make improvements towards handling this issue, but it is still appears to be half baked.

Have you figured out something that I have yet to read about? Are you the guy/girl that has the answer? If you aren’t, have you thought about the possibility of users accessing your database other than using the application it was intended for?

To me, it almost seems as though the ultimate solution to this problem is to sign the application code and then in SQL Server, per database, say what certificate is allowed into this database. That could be the certificate of a user or a certificate of the application. By doing the user and application would people like DBAs could still get to databases using any application and end users could access the databases only with the “approved” applications.

Thoughts?