SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Application user group security


Application user group security

Author
Message
Mike Wiz
Mike Wiz
Forum Newbie
Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)

Group: General Forum Members
Points: 5 Visits: 66
Greetings everyone,
I was wondering if you could help me with some suggestions on how to increase the security around my SQL 2008 R2 database server.
I currently have a third party application that uses a domain group (xxx\APP_ReadGroup) for authentication, in order for the application to access the database that same domain group requires db_reader to the database. I cannot change how the application is written so I cannot assign a SQL account that the application would use to read the database.

I'm trying to prevent users that are in the domain group from opening an ODBC connection and viewing the underlying tables and data.

Any thoughts or recommendations?


Thanks
-Mike
Mike Wiz
Mike Wiz
Forum Newbie
Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)Forum Newbie (5 reputation)

Group: General Forum Members
Points: 5 Visits: 66
I already have the instance running on a non-default port.
Erland Sommarskog
Erland Sommarskog
SSCertifiable
SSCertifiable (5K reputation)SSCertifiable (5K reputation)SSCertifiable (5K reputation)SSCertifiable (5K reputation)SSCertifiable (5K reputation)SSCertifiable (5K reputation)SSCertifiable (5K reputation)SSCertifiable (5K reputation)

Group: General Forum Members
Points: 5012 Visits: 875
So that application is a two-tier application and users are members of that group?

In that case, your only option is to put the application on Terminal Server/Citrix etc, so that when users log in on the TS, they directly get into the application with no possibility to get out. Furthermore, the network admin needs to segment the network, so that users cannot access SQL Server from their desktops; SQL Server is only visible from that terminal server.

Erland Sommarskog, SQL Server MVP, www.sommarskog.se
Orlando Colamatteo
Orlando Colamatteo
SSC-Dedicated
SSC-Dedicated (37K reputation)SSC-Dedicated (37K reputation)SSC-Dedicated (37K reputation)SSC-Dedicated (37K reputation)SSC-Dedicated (37K reputation)SSC-Dedicated (37K reputation)SSC-Dedicated (37K reputation)SSC-Dedicated (37K reputation)

Group: General Forum Members
Points: 37900 Visits: 14411
Do you control the connection string the application uses? If yes, are the users in the group prevented from seeing the connection string either due to the architecture or the fact that the information is compiled into the app or in an encrypted config file? If yes again then you could add an application name to the connection string and setup a login trigger to deny logins unless the application name were what the application had setup in its connection string. This is technically only an obfuscation, not security, but it could tighten things up a little.

Hosting the app in a virtual desktop environment, preventing the use of client tools in that environment, and locking down access to the instance using network segmentation is a complete solution.

__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search