i am starting to use data masking on GCP.
Searching the net I did not find anything. I wanted to know if someone had also used a KEY to strengthen crypting
thank you
Hello
BigQuery supports data masking. You can use data masking to hide sensitivity data. To apply data masking to columns first you have to set up a data catalog taxonomy with policy tags after that you have to create data policies for policy tags and then you have to set policy tags on columns. This way you can hide your sensitive data.
BigQuery automatically encrypts all data before it is written to disk. The data is automatically decrypted when read by an authorized user. By default, Google manages the cryptographic keys on your behalf using the same hardened key management systems that we use for our own encrypted data. Each BigQuery object's data and metadata is encrypted under the Advanced Encryption Standard(AES). If you want to manage the key encryption keys used for your data at rest, instead of having Google manage the keys, use Cloud Key Management Service to manage your keys. This scenario is known as customer-managed encryption keys (CMEK).
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.
I have .NET Core Web API microservices with MS SQL and elastic search(NoSql). I want to encrypt PII(Personal Identifiable Information) both in Elasticsearch and MS SQL database. Which is better option to use .NET data protection API or always encrypted?.
If I use always encrypted then it will only work with MS SQL. Elastic search + logging will require handling it separately so is it better to encrypt in API using data protection API?.
Documents say that data protection API is only meant for temporary data.
Is there any other better way to protect data other than above too?
Any common pattern or strategy for this?
Depending on your company's industry and internal policy, you might be required to encrypt data AT REST as well as IN MOTION.
Logging PII should be strictly banned. Only log account's internal IDs that can not identify a user, dont log usernames/userids, just account id. Do not log account numbers etc.
As an alternate to elastic search, you could break down the PII data points in to multiple systems to avoid any one system's compromise leading to PII leak.
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've got a problem scenario w.r.t data cyphering or encryption/decryption in SQL Server 2005.
Scenario:
There is a specific table in the database
The table has a column, let's say "Credit Card"
The requirements is that the content or data in this column should be encrypted
Required (plausible) solution:
Data that is inserted in this table's column should be encrypted, i.e., is unreadable to people running direct queries on the database and/or table; or only by using a specific decryption logic, which requires a KEY of some sort
While reading the data in any application, the method-of-decryption should be easy, maybe KEY based
The process or methodology should be easy to use
But difficult to break
Please give me some suggestions or solution in this regards.
Thank you.
you encrypt data with a symmetric key
you encrypt the symmetric key with a certificate
you encrypt the certificate with a password
periodically you generate a new symmetric key to encrypt new data
priodically you rotate the certificate and re-encrypt the symmetric keys with the new certifictae, dropping the old certificate
Application requests password from the user and opens the certificate in the session. It then uses DECRYPTKEYBYAUTOCERT to encrypt the data. This is the general industry standard. It protects data rest and guards against accidental media loss as well as access from a person not knowing the password.
You will find a lot of bad advise ont his topic. Any scheme that is 'automated' and does not requests the user for a a decryption password is wrong. If you want 'automated' encryption or decryption you should look into Transparent Data Encryption which protects agains accidental media loss. TDE does not protect against other users browsing the data, if they have access priviledges.
Try looking into the DecryptByKey function.