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.
Related
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.
As i need to synchronise a CouchDB with a SQL Server i need your help. I'm totally new to this and I don't really know a proper way to implement this. Is it even possible without typing thousands of lines of code? If it is, what's the easiest way to do that?
Moving data one way or the other in a specific case should be straight-forward. Read and parse the changes feed, convert the JSON documents to SQL statements that you then execute on the SQL Server side.
The general case (bi-directional, continuous sync between an MVCC and a non-MVCC database) is a hard problem without keeping extra state somewhere.
CouchDB has first-order support for conflicted documents, SQL Server does not. If you need your synchronisation to be bi-directional and stand up to concurrent modification of documents you will have a problem: CouchDB will quite happily accept multiple versions of the same document, a concept which has no direct equivalent on the SQL-Server side.
I got a question about encryption in SQL: encrypting data in the application's code (C#) and storing the encrypted data in the database has much less overhead compare to using the build-in SQL encryption options.
I like that:
You don't have to worry about making sure you'll be able to decrypt the data if you restore the database on a different server or when using SQL replication. I know that you can generate a special key that will allow you to do that but again, too much overhead.
It creates a total separation between the encryption method and the encrypted data.
Validating user password is done via the application's code by comparing user input with the hashed password. I don't think anyone need to run a query to check how many users have a specific password so we are good there.
On the other hand, if the encrypted data is a credit-card #, running a query to know when a specific card was used is not an unusual task.
To solve this problem, I'm thinking to use a SQL-CLR function to validate encrypted data. It will be used only for validation and not for encryption.
I wonder how safe is this going to be, especially if I would want to create some stored procedures that will relay on this user function to be able to query for data.
Thanks!
You are just asking for PCI problems I think. Why do you need to know when a specific card was used? For purposes of analytics/reporting or investigations/disputes/etc.
Your merchant processor (I am assuming you are a merchant based on the post) likely has ways to tokenize the actual card number at the point of sale. That token will still allow you to do analytics/reporting.
Storing encrypted data in the database, which was encrypted in the application layer, and then providing a way to decrypt in the database would likely ruin all the benefits of encryption.
Could you encrypt the card number in your C# app and then query that database using the already encrypted value?
Can you help with “validate encrypted data”?
I want to distribute an SQL 2008 database to a client and set it up so that the only way to access the data in it is through my application. Can I use Truecrypt for that? Can you think of any other solution?
No, is not possible. This is asked repeatedly and the answer is the same: protecting the data so that is only usable from one application is DRM and SQL Server does not do DRM. There is no cryptographic/encryption or authorization/permission mechanism you can set in place to prevent a legitimate administrator from seeing and using the data as it sees fit, including granting other applications permission to use your application data.
At worst you can encrypt all the data in the client and store only the encrypted blobs, thus rendering it unusable to any other application. This approach looses any advantage a relational database offers (data cannot be searched, queried, indexed, foreign relations and constraints cannot be enforced etc) rendering the SQL Server absolutely useless for your application. Besides, even in this case, short of using a hardware module, the data is not trully protected since the application cannot embed any encryption key in a secret fashion (any key embeded in the app, no matter how obfuscated it is, can be retrieved, always) and relying on the user to provide a secret password means the user can simply decrypt the data.
If you want to use a DRM scheme (which you are actually asking for), use a DRM product.
I've taken a quick look at Truecrypt and it doesn't look like the tool for what you're trying to do.
You should look at SQL Server Logins, Users and Roles. How you use these will depend on how you setup your database connection. If you can provide more information about how you are connecting I can try and help further.
Quick q, could be a silly one given my (lack of) findings on Google so far.
I have a Database. In this database is a Table with some Data. The Data is a large BLOB but can't be compressed (for reasons out of my control).
I have an Application that talks to this Database. I would really like to be able to ensure that the Data is compressed during transit.
As I understand it, the Database Provider would handle compression etc.
Is this the case? Are there settings on common ones, say SQL Server to enable compression?
For SQL Server, I found this "connect" entry, but no: I don't think TDS is currently compressed. You could (although I don't like it much) use SQL-CLR to compress it in .NET code, but it could have too much overhead.
I know it isn't an option in this case (from the question), but it is usually preferable to store BLOBs the way you want to get them. So if you want to get them compressed, store them compressed. SQL isn't a good tool for manipulating binary ;-p Such a strategy also means that you aren't using vendor-specific features - just the ability to store an opaque BLOB.
If your database access layer does not provide compression, you can set up a VPN link between the database server and the application host. Most serious VPN solutions compress data in transit. OpenVPN is a simple and easy to set up solution for quickly creating a tunnel. Data is compressed in transit. Probably won't be as efficient as a native compression, but it's a possible solution. And you get encryption thrown in for free :).
SQL Server 2008 is the first version of SQL Server to natively support compression of backups. Pre 2008, you need to do it with third party products.