I have a web app which my customers use to allow their employees to exchange documents. So, employee A1 can upload a document which employee A2 can later access given that both are employees of customer A. However, employees of any other customers are not allowed to access files uploaded by A1.
I would like to extend the web app to support secure documents. This means that I would have to encrypt document content before storing it on my server. In order to reduce liability I would like NOT to be able to decrypt the document content. So, ideally the content would be decrypted on the client (browser) side.
I have considered solutions that require an extra decryption/encryption service to be deployed on the customer side, but I don't like the extra management overhead that they require.
Assuming that my customers are large corporations and would have the typical infrastructure, e.g. LDAP, how would you propose to solve this problem without deploying extra services in customer environment?
Related
I’m looking for some advice with regards GDPR and firebase, I’ve looked online and apparently firebase is GDPR compliant as it stores data securely during transit and the firebase servers themselves are encrypted. So if that’s the case would I even need to encrypt personal data locally before sending it to firebase?
Currently I’m encrypting all personal data but the issue is that I want to have an autocomplete function that searches for customers as the user types. Now this wouldn’t work currently as a search for ‘sha’ would not find ‘shaun’ because shaun is currently encrypted. So I’m wondering whether I even need to encrypt customer details at all as firebase is encrypted itself. The only issue is that me as a database admin can see everyone’s details in the database but surely that’s the case with all database admins in most apps as you can query the data in there to your hearts content and see everything about everyone?
As long as you are not sharing this data for any purposes outside of the apps terms and conditions this should be ok shouldn't it?
So a few things first , when you encrypt data at the DB level , any usage of that data at the application layer has to go through a level of decryption .
So in the example that you outline the autocomplete feature ideally will be served by an API and the API at the back-end will take the encrypted data through the decryption process to keep it in memory and return to the client appropriately.
Also it is not OK to assume that admin cannot go rouge , most of the data breaches and leeks happen from internal source. So it is better to keep the PII as encrypted in the DB.
We are building a multi-tenant cloud-based web product where customer data is stored in single Database instance. There are certain portion of customer specific business data which is highly sensitive. The sensitive business data should be protected such that nobody can access it except the authorized users of the customer (neither through application not through accessing Database directly). Customer want to make sure even the platform provider(us) is not able to access specific data by any means. They want us to clearly demonstrate Data security in this context. I am looking for specific guidance in the following areas:
How to I make sure the data is protected at Database level such that even the platform provider cannot access the data.
Even if we encrypt the Data, the concern is that anyone with the decryption key can decrypt the data
What is the best way to solve this problem?
Appreciate your feedback.
"How to I make sure the data is protected at Database level such that even the platform provider cannot access the data"
-- As you are in a Multi-Tenanted environment, First of all you would have to "single tenant your databases" so one DB per customer. Then you need to modify the application to pick up the database from some form of config.
For encryption as you are in Azure you would have to use the Azure Key vault with your own keys or customer's own keys. you then configure SQL to use these keys to encrypt the data. see here and here
if you want the database to stay multi-tenanted, you would need to do the encryption at the application level. However this would need the application to know about customer keys, hence I dont think that this would be a valid solution.
"Even if we encrypt the Data, the concern is that anyone with the decryption key can decrypt the data" - yep anyone with the keys can access the data. For this you would need to set the access controls appropriately on your key vault.. so the customer can see only their keys.
In the end as you are the service provider.. the customers would have to trust you some what :)
I'm trying to create a service based on an Azure SQL Database backend.
The service will be multi-tenant, and would contain highly sensitive information from multiple "clients" (potentially hundreds of thousands), that must be strictly isolated from one another and secured heavily against data leaks. "by design"
Using so many individual databases would not be feasible, as there will be a lot of clients with very little information per client.
I have looked into the transparent encryption offered by Azure, but this would essentially encrypt the whole database as one, so it would in other words not protect against leaks between clients or someone else; due to development errors, or hostile attacks, and it's very critical that one "client's" information never comes into anyone else's hands.
So what I would really like to achieve, is to encrypt each client's data in the database with a different key, so that you would have to obtain the key from each client (from their "physical" location) to de-crypt any data you might manage to extract from the database for that particular client, which would be virtually impossible for anyone to do.
Is it clear what I mean?
Do you guys have any suggestions for me on how to manage this problem, or know of any third party solution that allows for this functionality? Any other advise?
You're looking at protecting/isolating the tenants "by design" in a single table, why not check out Row Level Security. You could configure it to serve up only the applicable rows to a specific tenant.
This doesn't directly address your initial question about encrypting the data with a separate key for each tenant; If you have a separate table for each tenant, then you could do this via Always Encrypted, but this would seem to have some complexity in key management, if you're trying to handle 200k keys.
AFAIK, there isn't a native SQL Server functionality to encrypt each set of rows that belongs to a tenant with a distinct key- but there may be some elegant solutions that I haven't seen yet; Of course, you could do this on the app side and store it in SQL and there would be no issues; the trick would be the same as the AE based solution above- managing a large number of keys.
Question 1
I have server side script, which connects to different data storages (ex. website database, ip-telephony server, web-analyst api). I storage passwords, tokens and other access data for data storages on server. That script runs by cron every day, not by user request.
In realy, i have many such scripts and hundreds accesses. All of these data storages belog to different companies, data in storages is very important. If server will be hack, hacker gets all of these accesses and companies data.
How can i secure storage for all of these accesses?
Question 2
Script from first question saves information into database. That information have to see only client in browser, programmers or databes admininstrator haven't see saved information.
Is there any way to encrypt data from cron server script and decrypt it only on client side in browser?
My company is building an ASP.NET HR application and we have decided to create one database per client. This ensures that clients cannot accidentally view another client's data, while also allowing for easy scalability (among other benefits, already discussed here).
My question is - what is the best way to handle security and data access in such a scenario? My intent is to use a common login/account database that will direct the user to the correct server/database. This common database would also contain the application features that each user/role has access.
I was not planning to put any user information in each individual client database, but others on my team feel that the lack of security on each database is a huge hole (but they cannot articulate how duplicating the common access logic would be useful).
Am I missing something? Should we add an extra layer of security/authentication at the client database level?
Update:
One of the reasons my team felt dual user management was necessary is due to access control. All users have a default role (e.g. Admin, Minimal Access, Power User, etc.), but client admins will be able to refine permissions for users with access to their database. To me it still seems feasible for this to be in a central database, but my team doesn't agree. Thoughts?
We have a SaaS solution that uses the one DB per client model. We have a common "Security" database too. However, we store all user information in the individual client databases.
When the user logs into the system they tell us three pieces of information, username, password and client-id. The client-id is used to lookup their home database in the "security" database, and then the code connects to their home database to check their username/password. This way a client is totally self-contained within their database. Of course you need some piece of information beyond username to determine their home database. Could be our client-id approach, or could be the domain-name requested if you're using the sub-domain per client approach.
The advantage here is that you can move "client" databases around w/out having to keep them synced up with the security database. Plus you don't need to deal w/cross-db joins when you're trying to lookup user information.
Update: In response to your update... One of the advantages to each customer having their own DB is also the ability to restore a customer if they really need it. If you've split the customer's data into two databases how do you restore it? Also, again, you'll need to worry about cross-db data access if the users are defined in a DB other than the home DB.
I've always been of the opinion that security should be enforced at the application level, not the database level. With that said, I see no problem with your intended approach. Managing accounts and roles through a central database makes the application more maintainable in the long run.
You may want to look into using the ASP.NET membership provider for handling the authentication plumbing. That would work with your stated approach and you can still keep all of the authentication data in a separate database. However, I agree with Chris that keeping one DB will utlimately be more maintainable.