Working with an application that needs to provide row and column level security for user reports. The logic for the row filtering an column masking is in place, but there are still decisions to be made about identifying users at report execution time.
The application uses a single SQL Server login to authenticate, as all rights are data driven within the application itself. This mechanism does not carry well to reports, as clients like Crystal and MS Office do not authenticate through the application (web and WinForms).
The traditional approach of using SQL Server logins and database users will work will, but may have one issue. In some implementations of the application, the number of users who run reports and need to be uniquely identified may run into the hundreds.
Are there any practical limits to the number of logins or users on a SQL Server database (v 2005+) where this approach may cause problems? Administration of the users on the database server can be automated by the application, but the potential number of credentials may be a concern.
We have looked into user impersonation techniques, but they become difficult to implement when a report client such as Excel authenticates directly to the server.
Edit: The concern is not concurrency or workload, but rather administration issues on remote instances where a local DBA is not available, especially when the server is not dedicated to the application. Interested in scenarios where the numbers of logins were problematic.
I've used your described approach (SQL Server accounts managed automatically by our application) and we didn't have any trouble. However, we only ever had a maximum of perhaps 200 SQL accounts. But we didn't experience any kind of administrative overhead except when "power users" restored databases without telling us, causing the SQL login account to become out of synch with the database*.
I think your approach is sound.
EDIT: Our solution for this was a proc that simply ran through the user accounts and called our procs that deleted/created the user accounts. When the power users called this proc all was well, and it was reasonably fast.
Related
I have a calendar-type WPF program that is used to assign the workload to a team. The events are stored in an Access database and the program is accessed by one person at a time by remotely connection to a computer. The team has grown and multiple people would need to access the program simultaneously. I can install the program on several computers, but where should I move the database? On a software like Dropbox/Onedrive, on a SQL online host? Thanks.
You can use a SQL Server on many Cloud platforms (though I am not sure Dropbox can host SQL Server natively). Azure (Microsoft cloud) is a very mature solution. You still should verify, now that multiple users will be managing data, that the database is backed up a regular basis and that any updates to data should be done within transactions that your code should be aware of. 'Aware of' means that if there is a conflict your code should either resubmit or notify the user that the insert/update/delete failed.
We have a big system running with thousands of users (some from android apps, other from the web app, etc.).
The system is distributed, with databases in two locations (within the same country). In one location there are 5 servers in the same network, and each one has a copy of the database (via replication).
Among the software developers, a few have direct access to the production databases. Sometimes due to technical support requested by users to modify some operations not possible from the system itself, the developers/support team have to access the database directly and modify some records.
We know this is not the ideal manner of working. But it's been like this since years.
Recently we have found a few problems. One day one person updated hundreds of records from a table by mistake.
Since then we are analyzing how to improve this access.
We are looking for some way of improving the security. We would like to have a two-phase authentication system in place. Something that asks the user for two passwords when accessing from Sql Server Management Studio...
Is that possible? Or is there any other approach we can use to improve the security but still allow devs/support team to access the production database when necessary?
Users also (currenty) have access via remote desktop to all servers.
At least we would like to KNOW when this access is being done.
Make access to PROD read only for those users. Allow them to write their scripts and then submit them for review at a minimum and testing if possible like any other deployable. Then follow standard deployment processes with someone who has access.
If my other answer isn't workable and these updates are always the same kind of fixes...you could create support stored procs maybe to do the fixes and only give permission on the procs...but this is highly dependent on the commonality of fixes being made and less preferable to my other answer.
I haven't used it myself but EXECUTE AS might let you give the users read-only permission while the procs would execute under credentials with higher access.
Background: [No copyright implementation]
[No copyright implementation] My company develops inventory control application for clients in the area where we don't have copyright protection by the government. The only option is to hide and protect things by ourselves. It is common for competitors here to copy other company's database and build front end on it and then start selling their own app.
The Problem
We use MS SQL server express edition and some times standard edition. We have found that any of customer can stop sql engine, copy the files from the pc where application was installed and then attach that database files into another system where they have full windows admin rights and that's it they can fully explore our database.
I am looking for
Is there any reliable solution to protect our database design being viewed by other people. Only our application may connect through the users we have created inside the db?
In past i had heard that sybase adaptive server has such functionality, windows users had no access in it and users were stored inside each db itself. there was no way to login if someone don't have password of the users stored in db itself.
Thanks
Your help will be highly appreciated.
As suggested by Sean, hosting it yourself or in a cloud service like Azure SQL DB is your best bet. Still no guarantee but makes it significantly harder to get everything but a lot easier to lockdown than alternatives. It's also a lot easier to manage and handle user requests for restricted data compared to something deployed onsite.
Outside of that, there's really no practical way to do it if deployed at the customer's site. Even if you lock down all logins and users (regardless of Windows or SQL Server logins) so no customer login has admin level privileges, you still can't prevent them from copying the database file, mounting it on a different instance where they have admin privileges or even just running it as an app to reset SA password. If they have physical access, all bets are off. It's only a matter of knowledge and time.
You can make it harder by encrypting the entire database and only your app holds the key. Users then have to either break the encryption algorithm (hard if done right) or your application that holds the key (easier but still not trivial). Both are expensive to do correctly and they really just delay, not prevent access. You will also introduce other problems like key management and rotation which, if not done right can result in customers losing access to their data.
You could leave a cookie trail (e.g. functions and tables that are active,look like they're part of the app and are tightly coupled to useful parts of the app but actually aren't related to the application's core functionality). That makes it easier to prosecute later but if the country has no laws protecting intellectual property, this will only be useful if the software is re-used or resold in a country that has such laws.
I am working on one large scale application (Web MVC Application), which can be used by enterprise level organizations later on where more than 50 or may be 100s of user are accessing the web at the same time and requesting data eventually to MS SQL Server.
My question is,
"Is it fine to use one user (in terms of connections and to fulfill all user requests) for all database connection by server side data access layer?"
What I mean is that whether there is any limit by MS SQL Server for one user to make number of connections simultaneously or not?
Your feedback will be very useful for me.
Thanks!!!
There is no limitation on the number of connections per user. Our website does this. All of our code accesses the database with one SQL Server credential.
There is, however, a hard limit on the total number of connections (around 30k) to the instance. We found this out the hard way with hundred of databases and connection pooling from tens of application servers.
We have a requirement from a client to protect the database our application uses, even from their local administrators (Auditors just gave them that requirement).
In their requirement, protecting the data means that the Sql Server admin cannot read, nor modify sensitive data stored in tables.
We could do that with Encryption in Sql Server 2005, but that would interfere with our third party ORM, and it has other cons, like indexing, etc.
In Sql Server 2008 we could use TDE, but I understand that this solution doesn't protect against a user with Sql Server admin rights to query the database.
Is there any best practice or known solution to this problem?
This problem could be similar to the one of having an application hosted by a host provider, and you want to protect the data from the host admins.
We can use Sql Server 2005 or 2008.
This has been asked a lot in the last few weeks. The answers usually boil down to:
(
a) If you don't control the application you are doomed to trust the DBA
or
b) If you do control the application you can encrypt everything with a key only known to the application, and decrypt on the way out. It'll hurt performance a bit (or a lot) though, that's why TDE exists. A variant of this to prevent tampering is to use a cryptographic hash of the values in the column, checking them upon application access.
)
and
c) Do extensive auditing, so you can control what are your admins doing.
I might have salary information in my tables, and I don't want my trusted dba's to see.
Faced with the same problem we have narrowed are options to:
1- Encrypt outside SQLServer, before inserts and updates and decrypt after selects. ie: Using .net encryption.
Downside: You loose some indexing and searching capabilities, cannot use like and betweens.
2- Use third party tools (at io level) that block crud to the database unless a password is provided. ie: www.Blockkk.com
Downside: You will need to trust a third party tool installed in your server. It might not keep up with SQL Server patches, etc...
3- Use an Auditing Solution that will keep track of selects, inserts, deletes, etc... And will notify (by email or event log)if violations occurred. A sample violation could be a dba running a select on your Salaries table. then fire the dba and change everyone salaries.
Auditors always ask for this, like they ask for other things that can never be done.
What you need to do is put it into risk-mitigation terms and show what controls you do have (tracking when users are elevated to administrators, what they did and that they were de-elevated afterwards) instead of in absolutes.
I once had a boss ask for total system redundancy without defining what he meant or how much he was willing to pay and sacrifice.
I think the right solution would be to only allow trusted people be DBA's.
It is implicit in being DBA, that you have full access, so in my opinion, your auditor should demand that you have procedures for restricting who has DBA access.
That way you work with the system through processes in stead of working aginst the system (ie. sql server).
To have person you don't trust be DBA would be nuts...
If you don't want any people in the admin group on the server to be able to access the database, then remove the "BUILTIN\Administrators" user on the server.
However, make sure you have another user that is a sysadmin on the server!
another way i heard that a company has implemented but i haven't seen it is:
there's a government body which issues kind of timestamped certificate.
each db change is sent to async queue and is timestamped with this certificate and is stored off site. this way noone can delete anything without breaking the timestamp chain.
i don't know how exactly this works on a deeper level.