1

We develop a SaaS solution that processes customer ERP data and provides analyses from it in a front-end. The software is a standard solution and should require as little customization as possible for the respective customer. Unfortunately, the ERP data is business-critical data (not legal protected data e.g. personal data, rather than corporate secret data), so processing the data on our cloud is not an option for the customer.

For this reason, we have considered three alternatives and asking whether there are any other options, or what is best practice in such a case.

  1. On-premise, i.e. each customer hosts its own instance on its own server
  2. Analysis at the customer's site: We provide each customer with an analyzer service that prepares the data. The rest of the application is hosted by us. If our application is requested by the customer, the frontend collects the data via REST calls from our servers as well as from the customer's server.
  3. Anonymize-deanonymize data: We provide an anonymizer service which anonymizes the data on the customer side before it is sent to us. In the next step we perform the analysis and send the results back to the customer. In the last step, the data is de-anonymized again by the customer and stored in a local database at his site. If our application is requested by the customer, the frontend collects the data via REST calls from our servers as well as from the customer's server.

Do you know any other methods/best practices and are there names for these strategies?

5
  • 1
    It seems to me that any answer to this question would be entirely customer-specific, and is essentially asking us to define your customers' requirements. Data Sovereignty can mean a lot of different things to different organisations depending on a wide range of factors, including the nature of the data they're holding, also including the countries those organisations are operating in, and also including data protection and privacy laws in those countries. Commented Dec 10, 2022 at 10:24
  • Are you building a product for sale in the marketplace or a bespoke product for this particular customer? If you're building a product for the marketplace, I'd look at other customers to see if the requirement that data is not processed on your cloud a typical requirement or based on this customer's desires or interpretations of some other guideline or regulation. Understanding the source of this requirement may lead you to say that this particular customer isn't worth the overhead that comes with any solution to their problem.
    – Thomas Owens
    Commented Dec 10, 2022 at 11:21
  • @ThomasOwens: It is a standard product for many customers. We have had many conversations with potential customers and the requirements are the same for all customers. I'll add this information in the post, thank you for your question.
    – Dennis
    Commented Dec 10, 2022 at 12:00
  • 1
    @BenCottrell: It is not legally protected data, but business critical data. Using a manufacturing company as an example, what are the individual parts that make up a product and what is the net cost, ...
    – Dennis
    Commented Dec 10, 2022 at 12:00
  • 1
    That still doesn't get to the root of what I was asking. There are plenty of businesses that use SaaS products and someone else's managed cloud infrastructure to store PII and PHI, which is much more protected than the "critical business data" you are describing. Either there's something else going on and you need to dig into these requirements or these customers are so risk-averse that trying to build a SaaS solution may not be feasible. Or, perhaps, a multi-tenant SaaS solution isn't feasible and you can stand up isolated cloud infrastructure for each client.
    – Thomas Owens
    Commented Dec 10, 2022 at 13:16

2 Answers 2

1

Talk with your customers. Figure out what they actually need.

Quite often, legal protections are sufficient, i.e. a contract that spells out that you will only use the data for the customer's purposes, that you will not use the data for any other purposes, that you will not combine different customer's data, and that you will not share the data with others. Such contracts are also the foundation for technical solutions. For example, if you're trustworthy enough to anonymize the data, you'd probably also be trustworthy enough to process the data directly (in either case, systems developed by you will have to touch the non-anonymized data).

Note that contracts are more convincing if your company is a real company incorporated in the same jurisdiction as the customer, i.e. not just an off-shore shell company that can't be reasonably sued. Vendors in the enterprise B2B space might also certify under ISO/IEC 27001 to demonstrate their intention to provide services in a secure and compliant manner.

I'm not a big fan of technical solutions to social problems like “trust”. However, technical solutions can help to foster trust. Let's look at your proposed ideas:

  • on-premise processing: this can be a great approach since it gives the customers the feeling that they control the software – even if this is typically not really the case. On-prem processing can also sidestep some actual compliance issues. On-prem deployment continues to be popular in the enterprise space.

    From a software-engineering standpoint, developing for on-prem deployment is quite different from building a SaaS solution. You can't do continuous delivery. You can't use arbitrary orchestration technologies. You will likely have to publish clear versions with a clear support period, and provide migration support when versions need to be upgraded. Nowadays, it can be sensible to provide your application as a set of container images or as a single container.

  • splitting the application into on-prem and SaaS parts: this can make sense if some aspects of your processing pipeline are particularly sensitive. However, it will generally combine the drawbacks of an on-prem solution with the drawbacks of a cloud solution, and will probably complicate your architecture. It will also complicate deployment: if your servers are to fetch data from the customer's servers, this requires that the customer's servers are reachable from your networks. While this is not impossible (e.g. by configuring suitable firewall rules or a VPN bridge), it is a lot more complicated. Complicated deployment could be friction that makes sales more difficult (if technical folks from the customer participate in the acquisition process).

  • pseudonymization: yes, it can be sensible to remove sensitive details before processing them off-site. But this is the kind of thing that looks good on a sales presentation without necessarily improving security.

    • This pseudonymization requires some level of on-prem processing, giving rise to all the issues discussed above.
    • Customers are likely concerned about third parties being able to draw sensitive conclusions from their data. By definition, such conclusions would still be possible from the pseudonymized data, since your off-site processing step seems to provide such value. A classic example for drawing statistical inferences about an organization from apparently de-identified data is the German Tank Problem.
    • Available pseudonymization techniques tend to be pretty weak, especially if they are supposed to be reversible (there's a fundamental tradeoff between the privacy/security afforded by an anonymization technique, and the utility of the anonymized data set). While differential privacy anonymization techniques are well-studied and can provide strong guarantees, they are inherently destructive due to adding noise to the data, and their probabilistic, query-oriented model may require a different approach to analyzing the data.
1

I do think that amon's answer is very good, I'd add a couple of thoughts as well.

My experience tells me that third-party audits against standards coupled with contractual obligations are usually sufficient for demonstrating the protection of data. ISO/IEC 27001 is one such standard, but it can be expensive and time-consuming. Although it's likely that you'll need something like ISO/IEC 27001 certificate or a SOC 2 Type 2 audit report eventually, I would recommend that organizations start with the Cloud Security Alliance's Cloud Controls Matrix and Consensus Assessment Initiative Questionnaire. It's aligned with these standards and a couple of others, and you can work through it to self-assess before bringing in auditors. You can even use these self-assessments to work with customers and potential customers to understand your current state and what they hope to see to plan improvements.

If, after more discussion, the requirement of not processing data on "your" cloud is not an option, I'd suggest thinking much more carefully about your product architecture. That would preclude using a multi-tenant SaaS model.

One option would be to continue to go down a SaaS model, but in a single-tenant solution. That is, you would instantiate a new and fully isolated cloud instance for each customer with no co-mingling of data. It may be easier to craft acceptable agreements under this model. You provide the infrastructure and software and maintain both while the customer provides the data needed by the service. Since you're maintaining both the software and infrastructure, you can roll out updates to customers, but I would recommend being careful to not get into situations where customers can refuse updates and you get stuck maintaining many different versions of infrastructure and software for different customers.

Another option would be to go down the self-hosted route. Package your system in a way that customers can install it on their own infrastructure and manage it.

I'm not sure that I would consider any other option. The options around splitting the application into on-premises and SaaS pieces have issues that I suspect would cause more problems than they'd solve.

Any time you have an on-prem solution, you need to rely on a third-party to keep their components up-to-date. They may have their own schedules and budgets and roll out updates at their pace. You may end up supporting various customers with different versions of the on-prem pieces or risk breaking functionality provided to paying customers. This seems like unnecessary complexity that you need to consider in your system design.

I agree that pseudonymization looks better on paper than it is for actual security. It will require some kind of on-prem solution for your customers, which brings up the same issues as above, but also adds important and likely custom security functionality where errors could end up exposing the data you are seeking to protect in the first place.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.