I am running a MS Access app using a few tables hosted on our native SQL server to facilitate easy integration with PowerBI and other apps. I am an intermediate MS Access user and new the SQL Server. I don't store anything critically sensitive in any tables and am happy with our normal security for data at rest. However, when my app or PowerBI requests data from the server, how is that data protected? I don't want the increased complexity that comes w/ certificate management and processing time associated with encrypting data. However, I don't want to be low hanging fruit for attacks when I request data from the server (i.e. attacks in transit).
Thanks!
First of all - security is about three things. Confidentiality, integrity and availability. Confidentiality means, that people are not supposed to see data that is not meant for them. Integrity means, that the data is what you expect it to be (no third party is able to manipulate it). And availability means, that the server is always up and running.
This is a simplification, but just to make the point that security is more than many of us believe. If your server is down, then the security is equal to zero.
Having said that, you wanted to know how to protect the communication channel. Sorry to say that, but the best thing we have right now is TLS, which requires certificate management. Look into this page to understand, how this can be configured: http://dba-datascience.com/ssl-or-tls-encryption-on-sql-server/
If you want to know how to protect your SQL Server even more (beyond the communication channel), look into the CIS Benchmarks available here: https://www.cisecurity.org/cis-benchmarks/. They are very technical (which is good), but may be also confusing a bit when you see it for the first time.
Related
I have a vb.net windows form application with a database on SQL Server 2008 on the ./SQLEXPRESS instance.
I have created a setup of my project using the link below..
http://msdn.microsoft.com/en-US/library/49b92ztk(v=vs.80).aspx
When a user installs my application, the database will be available for him, and user can just export the SQL Server database.
How can I secure my database so that user shouldn't have a easily available copy of my database?
I thought of creating a new password protected server (as I have created the database in above walkthrough)... while installation of my application on user's pc, other than ./sqlexpress. And a complete copy of database used by my application will not be simply available for user to just export and get a copy of my database.
So could anyone please guide me...
The question is; how far do you want to go to protect your data?
Better protection of your data usually comes at the cost of more development time and likely less user friendliness, for example due to lower performance (encryption is not free). More complex code usually results in more support requests too.
Where the best balance is depends on your business model (if any) and on your user requirements.
Keep in mind that anything you deploy to an end-users machine is in the end vulnerable. If something is valuable enough there will be people trying to steal it.
So, you could argue that the best protection is not to deploy the data at all. You could back your end-user application with a web service and keep the data on your own server, for example in the cloud.
I've found however that you sometimes just need to trust your users. If you build a good product that makes them happy, they have no reason to steal from you. In fact, they are probably glad to pay you.
If you decide that you need to deploy the data and that you need to encrypt it, you should think about why you chose SQL Server.
What database features do you need exactly? Do you need a fullblown database server for that?
Any local admin can gain control over any SQL Server database in seconds so the built-in SQL server authentication will not bring you a lot of benefits.
You could switch to SQLServer CE and keep the database within your application. That would make the database a lot harder to access for a regular user.
If all you're doing is looking up words, you may be better off with a different storage engine like Lucene.
Lucene is actually a search engine, so it's highly optimized for matching words or parts of words.
You can run Lucene inside your .NET application so you don't even need the end-user to install SQL Server. There is a .NET version of Lucene here.
Lucene however doesn't protect your data. There's tooling available that will allow anybody to view and extract the data from the stored index files.
Since Lucene is open source though, you could extend it to support encrypted data storage (see this related question).
I am planning to make a VB.Net application that is hard coded to access an MS SQL database hosted remotely on a web server. Is there a way for someone using some packet sniffing (I think it is called) program on the client PC to somehow know what password was used to access the database? I don't need to know how it is done, I just need to know if it can be done so that I know if my approach is safe enough.
Thanks!
If you only care about protecting the login to the database, then you're OK, according to this MSDN article:
Credentials (in the login packet) that are transmitted when a client application connects to SQL Server are always encrypted.
But if you also care about protecting the data, then you should read the rest of the above MSDN link to learn about enabling SSL to protect the rest of the data stream.
Note also this older article which gives a caution on using ODBC connection (rather than the native tyep). I doubt you would be doing that, but just thought I'd mention it.
From a client machine, it is unlikely that your database information can be sniffed. However, if your application "leaks" information, it is possible for an outsider to get sensitive information about your database. For example, if you have the CustomErrors parameter set to "Off", and your database is inaccessible for any reason, users may see your database's address and can then proceed to attack it using brute force or known exploits. There are other ways you can leak sensitive information this is just one example.
In general, it is not ideal to have your database open to the internet -- it is generally advised that your database be behind one (or two in case of a DMZ) firewalls. If you can control this, you should move it somewhere more secure. Or else even without your application leaking its address, a port scanning "war dialer" will eventually find it and alert the "bad guys" to its existence.
I only starting to learn about SQL Azure, have spoken to some potential clients, they say they have not chosen Azure due to the private nature of their customers information.
Reading about Azure it has firewalls to prevent unauthorised access.
I was just wonder what other way I could market Azure so that clients who potentially want to use it would not be concerned about privacy issues.
Also as I understand Azure supports Hybrid solutions where you can store data locally or remotely?
Thanks
SQL Azure is a public service and the data is stored somewhere in the cloud provider facility. With all security measures including firewalls and sentry dogs the data is still under zero customer control.
So the provider could do some backup and store it for some very long time and you might want to destroy the data ASAP and will be unable to have it done.
Also here's what technically could happen (not that I'm saying it is likely):
the provider might dispose of undestroyed hard disks
a bug could cause the authorization to fail and allow an unauthenticated user (because you see, you don't control what software updates the provider applies)
the provider employee might be bribed and copy the data
So if the user really wants privacy (or the laws say the data he deals with must be processed according to certain requirements) or he wants actual control on how the data is dealt with then a public storage service like SQL Azure is technically inapplicable for him. You trying to market Azure as providing the same level of control and security as a local facility would provide are deceiving the customer.
Sad but true and you can't lie to the compiler. There's no such thing as control over your data in a public storage service. Risks of negative outcomes are perceived as rather low, but they exist and they are real.
Yes, the Azure service bus has connecting private and public clouds as a feature. Keeping sensitive data locally may be what your clients want/need to push parts of their infrastructure to the cloud, although it will take some effort for sure to keep that separation clear, and I'm not just talking technically.
That said, marketing Azure to a client that's not ready for the cloud may very well lose you the entire deal, so make sure you're not pushing anything they aren't ready to cope with to start with.
A good starting point is the Windows Azure Trust Center to learn about Windows Azure privacy and security.
There's also a 7-part Windows Azure security best practice series on the ISV Developer Community Blog. Part 1 has links to the remaining entries, at the end of the post.
Microsoft's data centers are run by Global Foundation Services, which has its own set of security and compliance. There you'll find a data center tour video
Just started looking into encryption using keys and certificates in sql server 2005/08 and although it looks very good I'm not too sure why I should use it over sql server security permissioning.
For example, I have a table with sensitive data in, such as user-name/passwords.
I can either encrypt the data using say ENCRYPTBYCERT, or simply leave as plain text and just apply permissions to the table for authorised users.
I won't be transferring this data over the internet, just accessing internally over the network.
Are there any other reasons to use encryption?
Well it provides more security if you encrypt at the DB level. It's tied to the machine for a start, so you can't (for example) backup the database, restore it somewhere else, and have at it. If you also encrypt the keys (in a web.config encrypted section for example), then you have just defended against several different potential attacks.
So if you were storing customer data (protected by privacy law), or CC data (obviously with due regard to PCI DSS), then encrypting it like this protects it, for example, from your own support staff.
And then... if you're assuming that your other security is rock solid, bad people will never be able to get access to the data, but if they did, and if it was encrypted, they're still getting nowhere.
I need to develop an application which stores data in a SQL Server 2005 database (the app itself will be either a WCF Service or an Asp.Net Web Service).
Now, this data is supremely confidential, and I need to have it stored in an encrypted form in the database.
So, I am wondering what the best practices are around this. I know that there is some encryption capabilities that SQL Server has in-built. Is there a 'for dummies' type of resource for this so that I can quickly get going.
Alternatively I was thinking that I could encrypt/decrypt in my C# code and not in the database - maybe have a layer which handles this just above the data access layer (is that a good idea)?
Look at this link for a good introduction with samples.
I think doing the data encryption in the application is better, because in that case the transferred data is already encrypted. Otherwise you have to use a secure channel between your app and the database server.
It depends on your needs, i would say.
Have you considered encrypting your data at the file-system level?
It's Windows 2008/Vista only, but it should give you what you need and it's what it's designed for.
Before you decide on an encryption method, you need to access what parts of the system are vulnerable. If the potential for unauthorized access to the database exists, does the same threat exist for your application? Someone could run your code through Reflector and determine what methods were being used to encrypt and decrypt. You can mitigate that exposure to some extent with the code obsfucators. If that concern is not a risk, then you may find it easier to encrypt your data at the application level.
Encryption needs to happen in a few different places depending on the application. For example a consumer site using credit card info needs to encrypt the connection over the network to prevent man in the middle attacks or snooping. when the data is stored in the database you need to encrypt the data so that a low level sales rep cant read and access the customers credit card info , in which you might want to implement column level encryption as appropriate permission in addition to this if your worried that one day the janitor at your data centre might steal one of your backups then you need TDE implement to encrypt data at the disk level.
Encryption has a performance overhead esp with regard to CPU usage more importantly the overhead depends on the alogrithim being used for exncryption.