I am working on company's confidential data. Is there any way we can hide this data from back-end and still can see from front-end application? User will have access to database and tables but can't see the data.
Some hints:
Handle permissions by restricting the access to the sensitive data to a single user.
Add encryption.
Note that some information, such as the passwords of the users, should be salted and hashed, instead of being simply encrypted. The difference is that en encrypted piece of data can be decrypted using a private key or a password. Data which is salted and hashed cannot be decrypted (while is still sensitive to brute force attacks).
Handle permissions and add encryption.
Remove the data from the database machine and move it to a safer place (for example if the SQL server is collocated for several projects and is accessed by many developers, while the app server is only accessed by a few trusted persons, moving the data to the app server might improve the security a little). This shouldn't prevent you to add permissions and encryption.
Don't store the data in the first place.
For example, instead of storing passwords of the users, you may use OpenID, and let Google and other companies deal with security. Instead of storing credit card information of your customers, you can use services of other companies such as PayPal in order to be sure that you never get credit card numbers in the first place.
Yes, there are many tips to hide data in SQL Server.
One of them is Database Views.
Create different views on different table base on your limited column of table and assign only select permission on that particular views.
Don’t provide a any grant on any tables.
I hope, this is helpful for you.
You can encode the sensitive data, so it will be stored in the database in an encoded form and being decoded upon retrieval.
Related
This looks a very nice feature, but what I understood its that only the app can see the unencrypted text of the columns, right?
Is it possible that the admin with a SQL query can see the unencrypted data? or does it have to be always from the app?
If yes, can you post a small query to show this
The answer is NO you cannot see encrypted data even if you are the data admin. The admin should not have access to Column Master Key (certificate). You can access it from a client machine that has certificate installed using SSMS or .Net application. Please check the MSDN blog
The new security layer addresses that vulnerability by keeping the
data encrypted even during transactions and computations, and by only
giving the client keys to decrypt it. That means that if anyone else,
including a database or system administrator, tries to access that
client’s database, the credit card information or other sensitive data
would just look like gibberish.
If you are an admin/DBA you can access plaintext data, if you have access to the column master key. To select and decrypt data, you can use any version of SSMS that supports Always Encrypted. Starting with SSMS 17.0, you can also insert, update, and filter by encrypted columns. For more details, please see:
https://msdn.microsoft.com/en-us/library/mt757096.aspx#Anchor_1
https://blogs.msdn.microsoft.com/sqlsecurity/2016/12/13/parameterization-for-always-encrypted-using-ssms-to-insert-into-update-and-filter-by-encrypted-columns/
We have a process where data is sent from one database to another for distribution. The process chosen at the time was to encrypt the data because of all the people that could access the database. However, de-crypting the data is a slow process.
What are the alternatives to securing the data on the servers to prevent access?
It all depends on your requirements.
If you really need to keep the data private from people whom have access to the database then you pretty much have no option but to encrypt.
If you are sending the data to other locations and it is the transfer itself that needs to be secure you can use encyption for just the communication, ie webservices over https or custom encryption over tcp/ip, or saving to flat files and encrypting it as a whole..
If the data itself needs to be hidden from the people whom have access to it then there is a question of how secure the data needs to be.. If you are just wanting to avoid clear text there are some pretty fast encryption algorithms that can be used, here is a List of different encryption algorithms.
But if you are storing things like medical history or banking information then you have no option but to either upgrade your hardware to improve performance or take the processing time like a man ;).
If we are talking about passwords, where you only need to know if the user entered the correct password or not, then you could hash the passwords with a salt, and compare with the database hash, read more about that here: Link.
Easy answer: none. The only way to prevent people with physical access to the database table (note: the database TABLE - most DBMS can set access rights for indivifual tables) from reading it, is encrypting the data. It really is that simple.
Couple of recommendations
Work with DBA to create roles and restrict access to sensitive columns. In this case you don't have to encrypt.
Few columns you have to encrypt due to regulatory requirements. Selectively encrypt only the columns having sensitive data.
Also use relatively faster algorithms like AES. You can also cache the crypto object if not already done.
I've been looking for finding the best solution to store highly sensitive information like an Amount or a balance in a banking application. Can I store that just as a numeric field or Do I need any encryption to encrypt that data? Am a bit worried about encryptions since these fields are frequently being accessed by the users. So when ever it gets accessed there needs to be some decryption mecahnism and to store back the new balance amount that again needs some encryption.
Or is there is a better solution for that.
Database is SQL Server 2008 R2 and the platform is .NET 4.0
This is an important topic to think about, there are lots of ways to do it.
However encryption in the best possible way when we have confidential data and to save things from Hackers you should surely encrypt it.
Take a look at this
http://msdn.microsoft.com/en-us/library/ms179331.aspx
and this
http://msdn.microsoft.com/en-us/library/ms174361.aspx
You should not need to store the data in an encrypted manner.
When it comes to security of data you should always work on preventing access via firewalls and correct login protocols.
Also only allows users to access data for which they have clearance.
When it comes to encryption - you could encrypt the disk but encrypting columns is not really worth the access time it will take in decrypting the data and if someone has access to the database invariably they will have access to the decryption routines.
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.
We have a system with 2 clients (which will increase). These two clients connect to the same server/database, however neither should be able to see the others sensitive information. There is however some shared non sensitive information.
There is also an administrative department who does work on behalf on both of the clients. They are allowed to see all sensitive data.
We currently handle this by holding a ClientID against the tables in question and with a mixture of views and queries check against the ClientID to control access for each client.
I want to move to a consistent handling of this in our system e.g. all views, or all queries, however I just wondered if there was perhaps an easier/ better Pattern than using views to handle this situation?
We're using Sql Server 2005 however upgrade to 2008 is possible.
Cheers
the most logical way is to have (indexed) views filtered by what each user can see.
add read/write permisisons to each client for their views. admins access the tables directly.
but it looks to me that each client is a logicaly separated entity form the others.
if that's the case you might consider having 1 db per client and 1 db for shared stuff.
admins can access everything, each client cas only access it's own db and read from common db.
a 3rd option is to look into schemas and separate your clients there.