I am new on bigquery my task is to encrypt only email column in bigquery. I can not use udf there so with query itself i need to implement that but i am not getting any buildin function for doing the same.
You could encrypt the email column on the client before storing it in BigQuery. You can then keep your key safely stored elsewhere and never expose plain-text email in the database. This still allows you to look up rows with a particular email address, you just have to send the encrypted blob as part of any query that you want to run.
Note that this still allows someone with access to your database to know which rows had the same email address. This may or may not be an issue for you (as I don't know why you need to encrypt the addresses).
If you don't need to be able to reverse the stored email addresses, but just want to be able to compare them, consider storing hashes instead -- you can use the SHA256() function to do this. If you want to make this even more difficult to reverse with a pre-computed lookup table, you might consider salting the hashes as well.
See:
https://en.wikipedia.org/wiki/Salt_(cryptography)
There is currently no way to encrypt your database (or individual columns) with a user-specified key, but you could open a feature request for such a thing on the BigQuery public issue tracker.
Related
I'd like to securely store an encryption key somewhere in an SQL Server database that is only readable by internal functions and SP's. Is there a way to achieve this without it being visible to any user accessing the database (no matter what the role).
What i'm trying to do:
I need to have a simple sort of "license key" as a new column for my individual users. The plan is to hash their usernames using a client-specific key (which is a concatenation of the above mentioned key and a product key).
A function would be created that:
Takes the product half-key as a parameter
Fetches the secure client half-key in the database
Combines them together into a complete client-specific key
Uses this key to hash the username into a final output
Ultimately what i'm trying to do is give specific database users "licence keys". Since the customer has access to the database, i don't want them to be able to do add licence keys to other users as well. If the above doesn't work, i'm also open to other suggestions to achieve this.
GDPR is causing some headaches in this office. We already have a database table in production, lets call it personal_data, that now requires some columns to be encrypted. We are using SQL Server 2012. I've read that columns can be encrypted and decrypted with a symmetric key stored in the database.
We have dozens of existing queries, stored procedures and views that join to this table, so we'd like to avoid changing them if possible.
Is it possible to encrypt the necessary existing columns and query them without modifying these existing queries?
My thought was that if we renamed the personal_data table to something else, then created a view called personal_data, that queried the personal_data table columns and handled the decryption there, so everything that referenced 'personal_data' would still work as before. But if this is possible, what are the pitfalls with this solution?
I would suggest creating another table, say _personal_data. Encrypt the data in that table and replace the current table with a view on the table that returns acceptable columns.
You can give everyone access to the view, while restricting access to the underlying table.
This is a reasonable interim approach. For GDPR and other privacy initiatives, I prefer stronger restrictions, with personal data being in an entirely separate database -- because that is easier to control access to and to log accesses.
SQL Server 2005 enables developers to encrypt and decrypt sensitive data using EncryptByKey and DecryptByKey functions
You can find a sample case illustrated at SQL Server Database Encryption
But this requires code update for INSERT, UPDATE and READ statements
For example,
SELECT
CONVERT(nvarchar, DecryptByKey(EncryptedData)) AS 'DecryptedData'
FROM myTable;
Instead of direct read as
SELECT EncryptedData AS 'DecryptedData' FROM myTable;
Another encryption method is SQL Server Transparent Data Encryption aka TDE. Once you enable it, you don't need to make any code changes to write and read data. But this is a protection for securing disk files at all not for specific data fields. And once you connect database with a valid connection all data is transparent to you.
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.
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 have been asked to produce a system that is the middle point in a bunch of systems that handles payments to a small group or people. For it I will be required to store the peoples bank details.
What is a good way of encrypting this data to be stored within the database and then decrypt the data when required to pass onto the next system?
For this project I need to use Microsoft SQL Server.
If you're using SQL Server 2008 the you can use the built in transparent data encryption (TDE). Check out and see if it fits the bill.
I encrypt the values at application level along with an encryption key, and then pass this encrypted value to SQL Server.
When decrypting I pass the encrypted values to the application, and decrypt before using them within the application.
I prefer this method as it keeps the encryption method seperate from SQL Server.
Otherwise, if a user was to hack into your SQL Server, including your encrypted values, and you were using a T-SQL User Defined Function, they would have the ability to decrypt the values, making the encryption worthless.