Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I have a web application using a database in SQL Server 2008. I am the developer of this project and this project has been hosted elsewhere.
I've delivered the project to the administrator. Now the administrator is able to connect to SQL Server but I don't want the administrator to be able to see the database tables.
Is there any way to do this?
I've seen this done before by the makers of ACT. Their product installs a new instance of SQL Server Express and as part of that process they encrypt the sa password for the instance. This makes it 'impossible' for others to connect to the database using anything other than their product and add-on tools.
I don't know exactly how they do it, but perhaps you could search for encrypting sa password or something similar and find out how to do it.
Shy of installing your own instance of SQL Server I am not sure how you would go about this.
Bear in mind that your application will need to then provide the ability to backup, tune, modify, etc the database as the DBA would not have access to the instance of SQL Server.
Incidentally, we threw ACT out once we saw this - I didn't, and still don't, like the idea of a black box running on one of our servers.
In the end, you'll probably find that this added layer of protection (for you, not the client) just isn't worth the aggravation. While you may have proprietary information in the form of the database schema the odds of the client reverse engineering your application and then making their own are slim. Even if they did, it is hard to make good software - they likely wouldn't get it 'right' anyway.
My advice, don't worry about this, focus on making your software great so there is no reason for them to roll their own or look elsewhere.
Simple: No, he is DBA. He can not do his job without the ability to work with the database. Get over your objections.
You cannot limit the rights of an administrator on a server.
The administrator also has access to pretty much all tables that store your encryption keys, so TDE won't work.
If he is a security admin or one of the other roles, that might solve the issue as by default such roles has no permissions on your data.
SQL Administrators normally have these roles to protect your data. They need it.
If the data is very sensitive, you need to use alternative means to secure it, such as applying your own encryption before saving the sensitive values. (AES etc.)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm new to SQL, and i'm trying to understand something basic about it.
Why do we need a server to connect to when using SQL?
In my very narrow vision of it, it just uses some databases, which could be implemented as arrays for example (or whatever it is that is implemented "backstage").
For example, if I want to set up a table in my computer and do some operations on it, what usage does the server has? Why can't it "just be there"?
I think the reason for your confusion is too narrow interpretation of the word "server" as a separate hardware box.
A server does not need to run on separate hardware, or even in a separate virtual environment. It could be another process on the same computer, or even a library within your process. What makes it a server is an ability to accept and process requests from clients. It does not matter where the server runs physically: as long as you follow a protocol in which requests originate on the client side, you have a server.
What you're envisioning (roughly) is referred to as an in-process database and they do exist for SQL. SQL Server is set up to be used by multiple users or applications so it makes sense for it to be a central server that many clients can connect to so they can share the same data.
If you only want to process data locally, there is SQL Express LocalDB, SQLite and a few others that allow you to essentially embed a SQL engine inside your application.
You are, perhaps, confusing SQL the language with SQL Server, a Microsoft product that implements SQL.
SQL itself has many, many implementations. Many of those implementations do not use a server. MS Access, SQLite, FileMaker are common SQL-using products that rely on file-sharing rather than a client-server setup to provide multi-user access. These products can all also be used on a single machine without sharing files.
There are also implementations of SQL that use CSV files for storage although these are less common.
Finally, many of the client-server SQL products offer related, smaller-scale implementations that do not require a server. These are generally implemented using file-sharing as well.
It depends on what you are needing. Some instances of SQL, such as SQLite3, are local and file based. They have no server. Most provide a server because of the problem they address.
But lets address why a server is needed. Consider a Microsoft Access application where the databases are files shared over a network. Suppose 5 people are working with the same file. They each search for something, and the entire file must be passed over the network. Suppose one edits a record. The next time the others do a search, they will have to load the entire file again. If the file is large this is a huge performance hit. This is why servers were created.
A server receives only the SQL. The server does either a search, or an edit, and returns only the data that has been requested. For any database of reasonable size the performance improvement is huge.
Another benefit of a server is access control. With a server you can have multiple accounts and control what databases and even tables they have access to, and what activities they are allowed to perform.
In short, the server was created to address the problems that arise when you have multiple clients working with a single database.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I have a program that accesses a local firebird database. It has write access to this database, and we need to be able to write to this database, but do not know the username/password.
Obviously, somewhere in the PC is a connection string/username/password to be able to connect to that database. What methods could I use to find this?
I've tried process monitor to see if it accesses any registry keys but can't see any.
I've checked the installation directories for configuration files.
I've decompiled some of the DAL DLL's but can't see any hardcoding anywhere!
The vendor is no longer, so we can't go to them.
Any advice appreciated!
If with "local" you mean embedded then you actually don't need to know the password - the embedded version doesn't check password. Quote from the "README_embedded.txt" file, chapter "2.3. Authentication and security":
The security database (namely security2.fdb) is not used in the embedded server and hence is not required. Any user is able to attach to any database. Since both the server and the client run in the same address space, the security becomes just an agreement between both sides which can be easily compromised.
So you actually need only the username, and for that you can use SYSDBA - the Firebird's superuser. Note that the username is still checked, even with embedded, to assign user SQL privileges.
In addition to the answer by ain regarding use of embedded, authentication in Firebird is handled by the server and its associated security database. This means that if you copy (or better: backup and restore) a Firebird database to a different server where you know the SYSDBA password, then you can simply access the database.
However if you want continuous write access from a different process to a database that is used by a Firebird server embedded in an user application: you can't. The embedded server (at least on Windows), does not allows external connections.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am crazy to know that, how login system works in large applications like Facebook, Gmail, youtube, yahoo etc. Once after entering credentials server is responding more quickly. How is that possible ?
There must be more db servers for storing user information. So my question is
How they look for authentication information over more db servers?
Do they look over all the db servers to check for a particular user and if so how it is responding more quickly ?
Do they allocate db server based on geographical location of the user ?
And do they also have more application servers and how these are interconnected with each other.
RDBMS have the functionality to link servers that issue distributed queries, updates, commands, and transactions on heterogeneous data sources.
The database system will use some form of cached information about the user, in SQL Server an execution plan is stored and used when a query is executed. The database management system will decide which execution plan to take in order to generate the fastest results or use a cached data set. Note: Google, Facebook, Amazon etc will lot of server processing power behind the scenes which will make it seem instantaneous. They will also have dedicated teams to manage their databases, perform indexes, tuning, optimization and identify bottlenecks.
The geographical location of the server could be a factor. The closer the server is to the user the faster they can get the information but IMO this would be a matter of nano/milli seconds difference depending on where their data center is located. If the server gets too busy then the load balance will migrate you/other users to a server with more available resources.
Yes. Using more than one web server is needed in scenarios like this and is tied in to part 3 of the question, which server you hit depends on how much available resources the closest server has and if it will accept your connection. They are distributed but the whole process seems transparent to the user, i.e. they think they are using the same server as every other client. They can be interconnected by using session management, Web Services and other interoperability techniques and technologies.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have SQL Server 2008 installed on Windows 2008 Server.
I've disabled built-in administrator password and created sa with sysadmin privileges.
Question is: Is there any way to access to database, or back it up. or methods to reset (and / or) get password for sa?
I want to secure my database.
Thanks.
I've disabled built-in administrator password...I want to secure my database.
If you think you can disable access to built-in administrators your are chasing a phantasm. Built-in administrators will always be able to access your database, the steps to gain access are clearly documented in Connect to SQL Server When System Administrators Are Locked Out. Your database must be deployed on a system on which you completely trust the system administrators, there is no work around for this basic requirement.
Most often this question is asked as some misguided attempt to protect the perceived IP in the database. The answer to that question is that what you want is called DRM and SQL Server does not offer DRM. If you are afraid of distributing the database to your users then use a service like SQL Azure.
Users who have to have access to the SQLCmd prompt would be be able to run perform such commands. You could access the database and reset passwords the console and do something like this:
ALTER LOGIN sa WITH PASSWORD = ‘newpassword’ UNLOCK
I want to install an application (ASP.Net + SQL server 2005 express) in local network of some small company for demoing it for a period of time, but I also want nobody even sysadmin have no permission on this database and any permission granting wants a secure pass that I have .
I just want my tables structure and relations and functions be hidden and encrypting the data have no advantage
I need to spend more time on this article Database Encryption in SQL Server 2008 Enterprise Edition that i found from this answer is-it-possible-to-password-protect-an-sql-server-database
but
1.I like to be sure and more clear on this because the other answer in this page says :
Yes. you can protect it from everyone
except the administrators of the
server.
2.if this is possible, the db have to be enterprise edition ?
3.is there any other possible solutions and workaround for this?
4.if I install a new instance with my own sa password , can i restrict other instances admins from attaching the mdf to their own ?
thanks in advance
These people can access your server or the SQL Server instance no matter what you do
anyone with physical access to the server
domain admins of the network
anyone with the sa password
a windows group with local admin and/or sa rights (which implies group policy etc)
You have to host your server offsite if you want no-one to get to log onto it.
It is that simple
In SQL Server, you cannot "password-protect" a database - what you can do is limit the permissions a given user or role has in your database.
You can DENY anyone access to your database - but that's a bit odd, since no one will be able to use it....
You can do all sorts of stuff to your database tables and logins - but a sysadmin will always be able to get around those things and get access to the database. As long as the sysadmin can get his hands physically on the server, I don't think there's any way to totally shut them out.
If you don't trust even your sysadmins, you have bigger problems.....
There's several different ways you could solve this problem.
Host it offsite - I think the easiest solution would just be to host it offsite. There's loads of cheap shared hosting out there which you could use.
Lock out the sysadmins from that server. Assuming you have root access and only you use/need that server you could change the root password and any other passwords on the server.
Do what you're currently doing and try to make something secure even when someone who shouldn't have access has root access to the server. This way sounds tricky and insecure even at best.
I have a contribution for (3):
I'm guessing (I might be wrong) you don't actually have sensitive information in your database, you just want to make it unfeasible for someone in the local network to use any of your stuff.
If that's the case, you could just make it harder for them to read your data by encrypting the data in the database and having your (compiled) code decrypt it before using it.
This way, any sysadmin who is just curious about the data or wants to change his hiscore to 13371337 will not want to go through the trouble of decompiling your code and/or cracking your encryption (for the duration of your demo) and your (assumed) problem will be solved.
I have no idea if this helps you at all, I guess I just want to say you might want to take a look at your problem again. Since you can't keep the sysadmins away from your stuff, you may want to take a different approach like making it less useful to them.
As discussed by the various other posters, you can't password protect a database - deny permissions - to the sysadmin. One alternative that hasn't been discussed is hosting it on a Laptop. Since this is a demo, you can host the Database and ASP.Net site on a laptop and hook that up to their Network - after Sysadmin permission of course - and have the clients test the application from your laptop.
This will allow you to protect the database from Sysadmins and provide the added benefit that if you want to allow them to see the database you can let them use your laptop and you will be there watching their actions on your database. This last benefit is something that you can't do easily with a hosted solution.
The above answers point 3. As for point 2, you will need the Enterprise Edition of SQL Server to take advantage of Transparent Data Encryption (TDE) as per the comparison link on MSDN. If you click on the Enterprise Security link at the top it will show a table explaining the different security capabilities of the different SQL Server versions and it shows that TDE is only for the Enterprise Edition.