We are having reporting applications such as tableau in On-Prem and wanted to use Snowflake for processing the data, When data comes from Snowflake to On-Prem is it encrypted? If not what are the workarounds?
It depends what you mean by encrypted. Snowflake data is encrypted at rest but when you read it is decrypted (obviously, or it wouldn’t be usable).
If you use a secure connection between Snowflake and your environment then it is encrypted until it reaches you. Whether it stays encrypted in your environment depends on how your environment is configured.
What do you mean by workarounds? Workarounds to what? Are you expecting Tableau to decrypt data on the fly?
Related
I am going to store sensitive data like SSN and bank account numbers in my SQL Server database. The database is located on a server separate from where the application code is run, and I have Security Groups set up to only allow inbound access to the db server from my app server IP. I have already implemented the IDataProtector API and am using it to store encrypted passwords in my db, so I was going to use this to store the SSN and bank info as well.
But I read about Always Encrypted today, which is a SQL Server-based method you can use to encrypt specific columns. From the Microsoft page: "Always Encrypted allows clients to encrypt sensitive data inside client applications and never reveal the encryption keys to the Database Engine (SQL Database or SQL Server). As a result, Always Encrypted provides a separation between those who own the data and can view it, and those who manage the data but should have no access."
If I'm mostly concerned with hackers getting into my db and stealing data, which one of these methods is more secure? The master key for Always Encrypted would be stored in the Windows Certificate Store on the app server. I honestly don't know where the keys for IDataProtection are stored since it's been awhile since I set it up. I don't have anything explicit in Startup in services.AddDataProtection().
After much research, I think I'll go with Data Protector for now. The main decision point was that I don't want to use Azure Key Vault for centralized key storage, and Always Encrypted does not offer many alternatives.
I found that I can't use Windows Certificate Store for the column master keys because my EC2 instances are on a load balancer/auto-scaler, and so the Windows environment could be rebuilt at any time and lose the keys.
We use SQL Server, soon to be upgraded to the latest version of SQL Server, which I believe is SQL Server 2017. I'd like to be able to move some of our databases to the cloud, at least for development. Our company has instituted a lot of security protocols, and some (important) people in the company are uncomfortable with PII information or corporate information being on the cloud. Not that I blame them. I've read that SQL Server databases can be encrypted, and have read some of the documentation. This may be the solution to me being able to put some of our data in the cloud.
I can't get my head around how one could write a query against an encrypted database, without that database being at least temporarily decrypted. Would the fields referenced in queries or views be converted to encrypted values for the query to run? Or, is there some other way this is handled. I saw some stats on the overhead of TDS, and while it's not pretty, it may be doable. Could anyone explain in not quite layman's terms how this encryption is handled?
When you are doing a search against encrypted data, you would have to encrypt your search query in with the same algorithm the data was encrypted against. This eliminates the possibility for LIKE searches and for you to be able to show the data back in plain text however.
I can't get my head around how one could write a query against an encrypted database
There is difference if you encrypt the database or data.
Often the database itself can encrypt the database (such as MSSQL), or the hosting infrastructure can encrypt the data storage. In that case - the data themselves are stored encrypted, but the encryption is transparent to the authenticated clients (authenticated client will query the data as before, nothing changes). The key is managed by the infrastructure or database.
Another option is storing the data already encrypted by the client, e.g. encrypting only PII by the client app.
Storing all data already encrypted would make either data not searchable or you will need to use deterministic (semantically non-secure) encryption. This is what previous answer suggested. For this there's even a nice tool CryptDB which act as an encryption proxxy over database queries.
do i have to secure the column master encryption key at client side, so that nobody can read it?
Is it correct that when somebody has the column and master encryption key data can be decrypted by an attacker?
Regards
do i have to secure ... so that nobody can read it
This statement can never be true. If the application needs to read a secret (the key), then so can an administrator on the site. If you have an application running at a client side, there is nothing you can do to prevent a determined client from finding the key. Ditto for an attacker that has compromised the location.
Always Encrypted scenario is for applications that do not trust their service hosting (think Azure SQL Database). The application has the key and can manipulate the data, and the data travels to the hosting service and is stored encrypted. The hosting service cannot decrypt your data. All this is the starting paragraph describing the feature:
Always Encrypted is a feature designed to protect sensitive data, such as credit card numbers or national identification numbers (e.g. U.S. social security numbers), stored in Azure SQL Database or SQL Server databases. Always Encrypted allows clients to encrypt sensitive data inside client applications and never reveal the encryption keys to the Database Engine ( SQL Database or SQL Server). As a result, Always Encrypted provides a separation between those who own the data (and can view it) and those who manage the data (but should have no access). By ensuring on-premises database administrators, cloud database operators, or other high-privileged, but unauthorized users, cannot access the encrypted data, Always Encrypted enables customers to confidently store sensitive data outside of their direct control. This allows organizations to encrypt data at rest and in use for storage in Azure, to enable delegation of on-premises database administration to third parties, or to reduce security clearance requirements for their own DBA staff.
Your understanding is correct, roughly speaking, Always Encrypted provides the following security guarantee, Plaintext data will only be visible to entities that have access to the ColumnMasterKey (Certificate). So you would have to ensure that your CMK is only accessible by trusted entities. Also, the best practice is to have the client application and database on separate machines.
I have provided a short detailed explanation regarding the security guarantee provided by Always Encrypted here. You might find this useful. If you have additional questions, please leave a comment and I will try by best to help
I am trying to establish a very secure table(s). As a matter of fact, I prefer the same settings to apply to all tables within the database. Basically, this database would contain sensitive information: PersonID, CreditCard, Names, Address, PINs.
Nobody has the need to query this database; NO person. The only thing that needs to access the database is the integration services during the ETL process. As a result, my strategy to "secure the database/table" is to limit the access to the table to just the service account for Integration Services in COMBINATION with using TDE (encryption at rest).
my questions are:
1) is this a good strategy? it's important not to allow anyone (including myself) to be able to query the database
2) how do I limit access to a table to just the service account in SSMS? I dont know how I can just give "SSIS" access and nobody else.
(I use SQL Server 2012 and SSIS 2012)
Thank you so much!!
I don't see how this would be a good solution. The problem is, someone could find out the password to the service user, resulting in access to everything. Also you couldn't restrict DBAs.
I would rather store all the information encrypted with a password that is not available to anyone. SSIS or whatever interface accesses the data would take on the role of encrypting and decrypting (if even needed). SQL Server also has some encryption options, if you don't have a corporate encryption method.
Also you could use a specific schema for the tables with sensitive data. You could by default deny permission to normal users for that db schema.
I'm working with Activiti 5.14, and I have a requirement:
All the data in the database should be encrypted.
So, was trying to come up with a solution encrypting the data before to pass to the activiti library, but now I need to lookup for another approach.
I was thinking about to intercept of the save database operations and save all the data already encrypted and read it decrypted. (I don't mind the performance at this point)
Is there any way to achieve this?
Thank you all.
Why don't you simply use an encrypted at rest database?
Oracle, sqlserver and db2 all offer this capability.