I'm new to SQL server and I have a question
I created a database on a SQL server local DB instance and then I copied the .mdf file of the database to a USB flash drive and I was able to open the database from a different user account'
So I want to understand why is it so? Does it mean that anyone can copy my database file and open it on their own server? And how can I secure that?
Thanks
Does it mean that anyone can copy my database file and open it on their own server?
Yes, as long as it's the same version of SQL Server. This is why it's critical to maintain control of a server running SQL Server and prevent unauthorized access to the file system or backups.
So I want to understand why is it so?
The same software uses the same format. Much like how an Excel document can be saved on one computer and opened on another, so, too, can a database. By default, SQL Server stores data in the easiest and most straightforward manner it can for best possible performance. Security of the data files is often a secondary concern as most SQL Servers physically reside behind locked doors and OS access is restricted to computer administrators with domain authentication.
If you're running SQL Server 2008+ Enterprise, you have access to Transparent Data Encryption which will encrypt the data files on disk. That doesn't prevent moving the database if you have full access to the original host system, but it does mean there are additional steps and it will be difficult to access the data by directly reading the data from the disk. Furthermore, you can also encrypt your backups (I believe SQL Server Standard and above supports this, I'm not sure about Express).
As far as Express LocalDB... your options are pretty limited. You can use NTFS level encryption, but that will impact performance as the DB engine is no longer aware that encryption is going on. Furthermore, anybody who can access the DB unencrypted would be able to access the DB files to copy, so you're not actually protected against inside attacks. You could also use BitLocker full disk encryption, but again, that will come with some I/O cost and, again, doesn't protect against inside attacks.
Finally, no matter what you do anybody with sa or dbo level access to the server will be able to read your data. You can choose to store only encrypted data in the DB, but that pretty much eliminates any advantage of using SQL, and your application would still need to store the means to decrypt it somewhere, which means someone could find your decryption key and work backwards from there.
If the server is a real production server and it's properly secured, people should be able to connect to the database (using the server name and the database name and some kind of authentication), but beyond that, no one except administrators should have any other kind of access to the server.
Specifically, no one but the administrator(s) should:
be able to see the .mdf file or the folder that contains it
have physical access to the server so that they are even able to plug in an USB flash drive
That's how it should be on a "real" server.
SQL Server LocalDB is a local-machine-only version of SQL Server Express for development.
So I guess that the machine you're talking about is a development machine.
But it doesn't matter if it's a production server or development machine - the following always applies:
Whenever someone has access to the actual physical machine, they will be able to copy the database files.
When someone has a copy of the database file, they will be able to restore it on another server and open it with an admin account, no matter what permissions you had set. An admin account will always be able to open it.
There's no way to prevent this, other than to make sure that evil people with USB flash drives will never have any kind of access to that computer, beyond remotely connecting to the database.
EDIT:
What about data encryption and special key?
I personally didn't know about it before, but there's already some information about it in the other answer - go read it.
TL/DR:
Moving the database becomes harder, but not impossible
Getting the data out of the database becomes even harder than moving
...but the OP isn't able to use it, because he's using LocalDB (=Express Edition), but Transparent Data Encryption is available in Enterprise Edition only.
Related
I want to deploy a .NET application on client machine. I don't know how to protect my database .mdf and .ldf files from copying. Is there any way to prevent them also from copying these files? I'm using SQL Server 2008 R2.
Short answer NO!
If they own that server there's little you can do.
If they are consuming your DB means they have a connection string to it. By using that connection string they can do a lot of things.
You can try to cryptography your DB, create just a handsome of users with specific crud operations permissions, etc.
But if they own the server they virtually have ultimate control over anything running on it.
And by the merit of just coping files, they can do what they want.
If you want to provide a service/application and don't want to provide clients to copy your precious data you ill need to host that by yourself or by a trustworthy third party.
I have some SQL server DBs attached to my instance. The problem is they can easily be copied from the physical folder and any one can attach them to his own instance and view data.
How can I make sure that when files are attached, they can not be copied from the physical location and can be copied only when detached from the instance?
Thanks
So it seems to me someone have access to the file system. Your database .mdf files can only be as secure as the file system. But here are the few things that will help.
You can encrypt the data before it goes into the database. Use a long encryption key, to difficult to bruteforce to be worthwhile.
Also you can consider to change the file extension. There's no law that says you have to use MDF and LDF.
IMO, you may put the database files in a obscure directory. Don't use MSSQL\DATA.
Hope all these tips will help :)
Considering it's SQL server I am assuming you are using Windows environment. The ideal situation would be to have it on a separate server where only few people have access.
If it's a smaller setup then restrict unwanted access to folders by applying security and only allowing yourself and trusted users access to the folders.
Have you checked out Transparent Data Encryption (TDE)? It's specifically intended to prevent people from accessing the actual files.
Transparent data encryption (TDE) performs real-time I/O encryption
and decryption of the data and log files.
http://technet.microsoft.com/en-us/library/bb934049.aspx
I don't think that as you said you will be able to copy the .mdf file while SQL Server service is running
You may disable the Builtin\Administrators user to restrict the Windows Authentication
A colleague I work with recently told me that SQL Express and MS Access were essentially the same thing; that does not seem to be an accurate statement. I know you can convert Access to a SQL DB and maybe under the covers they are similar, but I would assume that the SQL DB engine and what is used to run access are not the same. Not only that, but the SQL statement syntax, etc. I know are not the same.
I am mainly trying to understand so that I am more informed about the versions.
Um, no, not the same.
First off, I need to clear up some terminology. MS Access is a Rapid Application Development (RAD) tool that allows you to quickly build forms and reports that are bound to relational data. It comes with a file-based database engine (Jet/ACE).
Access the RAD tool can be used with many different backend databases (Jet, SQL Server, any db that supports ODBC, etc). I have to assume your colleague was specifically commenting on Jet/ACE, ie the database engine that MS Access uses.
I think the single biggest difference between the Jet/ACE database engine and MS SQL Server Express is that Jet/ACE is file-based and SQL Server Express uses a client/server model. This means that SQL Server Express requires a running service to provide access to the datastore. This can complicate deployment in some scenarios.
SQL Server Express is really just a throttled-back version of SQL Server: max database size of 4GB (10GB in 2008R2), only uses a single physical CPU, etc. These limitations are imposed to prevent large organizations from using the freely available Express edition in place of a full-blown SQL Server install. The upshot to this is that SQL Server Express offers a truly seamless upgrade path to SQL Server. It is also (generally speaking) a more robust and fully featured database management system then Jet/ACE.
Similarities
relational database management systems
written by Microsoft
Differences
MS Access
File based
free distributable runtime (2007 or later)
RAD tools (form/report designer)
uses Jet SQL
max file size 2GB
SQL Server Express
Client/Server model
free
no RAD tools
uses Transact-SQL
max database size 4GB (10GB for SSE R2), max one physical CPU
I think what your colleague had in mind was SQL Server CE, which is a super-lightweight embedded database, which is still (IMO) far superior to Access in database-management aspect. SQL Express cannot even be compared with Access without offending the former.
Here are the datasheets for both products so you can see some hard facts on the difference between the two databases.
Access:
http://office.microsoft.com/en-us/access-help/access-specifications-HP005186808.aspx
SQL (Express is listed on the far right column):
http://www.microsoft.com/sqlserver/2008/en/us/editions-compare.aspx
The comment I have always read is that Access is great for single user single access database use, the minute you scale beyond a single user look elsewhere. While that may be a "bit" of a stretch, Access really does not do well in a multi-user environment. From experience we've had a client who has ignored and ignored our requests to migrate a backend database from Access to SQL, and there have been numerous occasions where we have had to restore from backups, or take the Access database offline due to corruption.
They are two completely different technologies with two different target markets. The database engines are indeed different, as you mention T-SQL is different than Access SQL.
You can "scale up" an Access database to SQL by creating an SSIS package or other tool to do the import, but this takes the Access schema and data and migrates it to a true SQL database. It does more than just attach the Access database or the like.
Anytime you need a "real" database I'd highly recommend looking at any of the SQL versions that are available over Access.
Just remember that with MS-Access you don't have size limitations if you play your cards right. There is no reason, for example, not to have many 2 to 4 Gig tables each contained singularly in their own database. Your ODBC applications can open a connection to multiple MS-Access databases and query the single table in each. So you can have a database containing trillions of records, stored in multiple MDB files. One company I went to work for was using a single MS-Access database to run a issue tracking system done in MS-Access forms. They could only use it one person at a time because of sharing issues that would lock MS-Access up. I wrote a Win32 Perl native Windows GUI user-interface to the database that was better at field/record validation, and my ODBC code was able to manage the connection for simultaneous user access. I managed the opening and reading and writing and closing of the database for each user through my Perl program. I did not leave the database open. I did not maintain a persistent connection for each user, but instead only maintained a connection long enough to retrieve a record for edit. Then I closed the connection until it was time to write the record back to the database. Also, I wrote my own record locking program logic by maintaining a user login table that contained the record id of the record a user was currently editing, then erased that entry when no longer editing that record. When another user went to edit the same record, the program checked if that record was currently open for edit by another user. The system worked flawlessly. MS-Access never locked up via ODBC and multi-user access. I even embedded the password to the database in my compiled Perl program so that no one could get to the data in the Access database other than through my Perl program.
I’m distributing an SQL 2008 database with my c# application (only the data, which I restore in the client’s local SQL server).
Is there a way to assure that the client can only access my data by using my application? (and not, for instance, using Management Studio, SQLCMD, etc)
Thanks, Nestor
Yet another form of the same ethernal quesiton that comes up about SQL Encryption... see Who needs encryption? at the DRM section:
"I would like to package my database
application in a form that would allow
a customer to use it, but without him
ever being capable to access the
actual data stored in it. I think
encrypting the database should help".
The answer is always the same: what you ask for is DRM, not encryption, and SQL Server does not offer any DRM solution. If you your application can access the data, so can the user from any tool of his choice. You are wasting your time trying to find a solution based on SQL encryption and all the claims to the contrary are snake oil. All 'solutions' will have a key management fault that will allow an administrator to retrieve the decryption key, always.
I have a database with data that i don't want anyone to copy around.
Now, how can i prevent other users to have access in the local machine, but whenever i want to work with, i am allowed.
And another issue I'm thinking, how can i lock the DB so if someone copy the .mdb file and try to attach it on another machine he/she couldn't see a thing?
There are many different kinds of encryption options available in SQL Server. If you don't want to have to re-write your application then the new feature in SQL Server 2008 called Transparent Data Encryption (TDE) is for you. It means you can encrypt the data files to prevent unauthorized users getting at the data from a backup or by copying the data files.
This MSDN link should be enough to get you started.
You probably want to use database encryption to achieve this. Then the mdb file will be useless.
Some links
http://blog.sqlauthority.com/2009/04/28/sql-server-introduction-to-sql-server-encryption-and-symmetric-key-encryption-tutorial-with-script/
http://msdn.microsoft.com/en-us/library/cc278098.aspx
http://technet.microsoft.com/en-us/library/bb510663.aspx
http://support.microsoft.com/kb/316898