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
Related
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.
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.
What I mean is being able to access it through Windows Explorer or other programs. I believe the answer is that it isn't possible. But I really want to know why it's not allowed. It seems that the files could be made available read-only through the network share.
You can't access the Filestream share directly and explore around. Any open to a Filestream file needs to be done using the path retrieved from SQL Server and by using NtCreateFile (or a wrapper) with the appropriate transaction context passed in through the EABuffer.
It is possible to create a new share and point it to the physical location of the files, however this is pretty pointless as there's no supported way to resolve a SQL Filestream row to a physical file location (the RsFx filter driver handles these conversions internally), the file location may change at any time due to concurrent updates / partition changes, and you'll need to relax security on the folder to an unacceptable level. It can also cause corruptions in the database if you move or delete files without the knowledge of SQL Server. Any locks held on physical files will interfere with deletes as mentioned in dportas' comment.
I agree it would be great to be able to browse a namespace of the Filestream files through explorer and open files directly through applications without requiring an application rewrite.
Yes it is possible. The point of filestream however is that you get that access via the filestream API rather than direct through the filesystem. Bear in mind that the file name could change without warning - for example updates may cause a new filestream file to be created. Possibly if you are holding file system locks (even shared locks) on a file that is needed by SQL Server then that may cause a contention problem. So if you access the data direct through the file system the results will be unsupported and may be unreliable - but then again it might work :-)
Yes it is possible if you are also using FileTables (I am using Sql Express 2017). When in Sql Server Configuration Manager, right click on your server instance, select Properties, and then go to the FILESTREAM tab. Check the "Allow remote clients access to FILESTREAM data". You may have to stop/start your instance. Now you can browse to the share, which is named according to your instance (in my case SqlExpress). In my database (SimioPortal) I had created a file (BlobStore) where I stored my files.
So, at the command prompt I can now type: dir \localhost\sqlexpress\SimioPortal\blobstore and see a list of my files. You can do a similar thing in File Explorer.
So here's the challenge. I need to use C# to back up a database locally from a remote database server and the only share we have is \\computer\c$.
If the answer is to back up to a location on the remote database server and then copy that local, assume there is not a share on the remote location. Just b/c I have access to the database does not mean I have access to the file system.
This Q/A looks close to what I want, but remember the regular account in the database will not have access to the network. Sample sql script to zip and transfer database backup file
With all of that in mind...anyone done something like this and care to share? Or have an idea of how to do this?
UPDATE: I was being vague on purpose. The context here is this:
I do not have access to files on the server where the database is.
I am running the C# from the client under the client's credentials, so I have full control of the client computer and can do anything in this domain.
I think I actually have figured out what we are going to do though:
Create a special folder in the AppData area of the current user.
Create a fileshare to that folder
Add rights to Everyone for that particular share and folder.
Process the backup based on that share.
Remove the share and reset the permissions.
In case anyone is curious what this question refers to: RoundhousE
Context? Oracle? MySQL? SQL Server? Db Size? Backup time? Availability requirements? Encryption requirements? Rowcount validation?
I'm guessing you're talking about SQL Server, based on the TSQL example- to which I'd recommend checking out DMO objects. Here's a primer- http://www.codersource.net/csharp_sqldmo_sqlserver.aspx.
Truthfully- the vague nature of your question- and the fact that it's context free gives me some heebie jeebies. Be sure to test in a test envrionment and not run on production data, ok?
The backup system of SQL Server runs the entire backup procedure on the server, which basically means that the file has to be put somewhere the database server can put it and has access to.
In other words, the file will be written from the server.
If you:
Cannot access files directly on the server, from the client, in any way
Cannot download files from the server, to the client, in any way
Cannot write files from the server, to a common place, that is reachable by the client in any way
Then you are left with one way: Reimplement backup.
If your actual question is this:
With all of that in mind...anyone done something like this and care to share?
Then I'm going to hazard a guess that the answer to this question is: No.
Are you sure you cannot change the problem to one that is solvable?
think I actually have figured out what we are going to do:
Create a special folder in the AppData area of the current user.
Create a fileshare to that folder
Add rights to Everyone for that particular share and folder.
Process the backup based on that share.
Remove the share and reset the permissions.
In case anyone is curious what this question refers to: RoundhousE
If you want/need to back up a database, then in general, for the purpose of guaranteed database consistency, the database server will need to be either completely shut down, or at least be completely in read-only mode.
Your question sounds like your "challengers" have taken you to task to back up a remote server while none of those conditions are satisfied. The only sensible answer to such a challenge is that it cannot be done.
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