Question

I’d like to know what application connected to DB and executing SPs.
(I want to limit SP execution to only my App – all other – eg MS SSMS would be ignored)

So is there a way to find out connected client name?

If not maybe you have other suggestion how to ensure only dedicated app is used
(App is using Windows’ integrated security)

EDIT: What problem I’m attempting to solve:

I’m working on built in app user right & roles module.
So, app receives from DB (via SPs) all fields and than business logic decides what to show (or not) for which user.

I afraid about more experienced user: he can run own app, connect to DB and omit all security restriction.
That’s why I want tu ensure DB talks only with this app.

Connection string param is some solution but quite easy to sniff – I wonder if there would be another option

Answer 1

The only thing that can be authenticated on Windows is a user. There is not secure way to establish the identity of an application. As a result any attempt to restrict access to a specific application can be defeated by a sufficiently motivated attacker.

You can keep a accidental login honest by adding a logon trigger. In the trigger you can check the declared “application name” from the connection string and close the connection if is not. This would deter somebody accidentally connecting to your server. However it would not deter a motivated admin from accessing the data, as the application name can be spoofed. Also if you have any sort of administrative and maintenance tasks, the administrators and the maintenance tasks need access to your database.

A slightly better approach is to control access to the data via an approle. The approle enables access for the application, you would still use your custom application logic for your content management restrictions (the ‘column’ restriction and other you quote). This would elevate slightly the bar so that only your application can modify and access the data. It would deter non-admins from accessing your data, but a privileged admin will be (will always be) able to do whatever he or she wants.

And lastly there is a even higher bar by deploying encryption. It takes a really determined administrator to surpass this and it takes an administrator that will have to take specific steps to find out your key passwords, he cannot discover them accidentally. As I said, a dedicated administrator will always be capable of accessing your data.

An alternative is to not deploy any barrier but instead use auditing to monitor the data. Tamper evident auditing can be done in SQL Server and advertising the audit is usually a strong enough deterrent.