Score:1

Server

System architecture for storing sensitive data separately without single point of access

Max Hudson

11/2/23, 8:55 PM

We're building a SaSS platform with support for integrations. Each client has multiple integrations. We'd prefer not to store these integration tokens in a centralized location, where there's a single point of access to all tokens for all clients.

Our current approach is to run separate servers for each client, with separate hosting accounts. This means in order to access all N clients accounts you'd have to know N sets of credentials. The only way to access those accounts would be to have physical access to someone on our teams devices.

Obviously that's not the most scalable solution...

We looked at having N EC2 instances under one account - they requires physical PEM files to access the server which we like - but you can just regenerate new PEM files from the one account, so there's a single point of access still.

There are suprisingly few/no results online about how to go about this - presumably because companies are just storing this information in a centralized way. The reason we considered it was especially important was because our database and system is relatively insensitive, but all of these integration accounts are sensitive (i.e. Quickbooks).

We limit what each integration token is able to do to the actions we need to take, but would feel best if there was no single point of access to them.

Are there any good precedents for this scenario or suggestions of a better way for us to go about this?

We're looking for something:

secure (no single point of access other than keys/passwords on a physical employee device)
scalable (low overhead per client, easy to make changes to the architecture)

1 + 6

security

amazon-ec2

amazon-web-services

node.js

Tim

11/3/23, 12:17 AM

I'd put everyone on one server, store any secret information in AWS Secrets Manager with a KMS CMK.

mfinni

11/3/23, 6:38 PM

i think having some diagrams might help explain the current and desired scenarios

Max Hudson

11/4/23, 11:36 PM

@Tim if we use a customer managed encryption key, how does the server decrypt the value (an integration api token - i.e. oauth2 refresh token) to actually make the request it needs to? If the server can decrypt any of these secrets, there's a single point of access, so if someone got on our server they could gain access to all integration keys - how would that avoid SPOA?

Tim

11/5/23, 7:27 AM

Almost every system is vulnerable if someone gets access to the server, often with database credentials. Secure your server(s) well based on AWS best practice, and based on your reluctance to do this I suggest you have an independent security firm review your design and implementation before customer information is put on it. There's a reason there's very little information on this sort of architecture online - because it's generally not a good idea.

Max Hudson

11/6/23, 1:25 AM

@Tim Of course securing your servers is important! Our independent security firm (who has reviewed our architecture) agreed attempting to eliminate a single point of access to potentially hundreds of customers' api keys was a major risk and compartmentalizing this kind of information was a standard security approach to reducing surface area. If have a clear solution/alternative for us to achieve the goal outlined that's super helpful - if not, I appreciate the input!

Tim

11/6/23, 3:33 AM

Security people love to say no. Their role is to reduce risk, and yes it reduces risk, but it makes the solution impractical and difficult to scale. Alongside risk you have to consider likelihood of being exploited and the impact if it is lost. I would simply put any integrations into AWS Secrets Manager with a CMK and ensure you use AWS best practice for security.

Score:0

Server

mfinni

11/2/23, 10:06 PM

Kind of a shopping question, but maybe something like hashicorp boundary. You use Vault to store the secrets, and you have identity management and proxies that authenticate and authorize access based on that identity. Depending on what exactly it is you're doing, the proxy+Vault combination can actually keep the sensitive secrets out of developer/staff hands entirely.

There may be other products that do similar things, I'm not sure I understand your use case exactly.

+ 3

Max Hudson

11/2/23, 10:33 PM

Hi @mfinni - thanks for the response. The issue has more to do with controlling access to a server hosting provider interface / the server itself. Typically with one account, and many servers you can access all of the servers from the one account (i.e. one AWS account can many EC2 instances). This is problematic for us because we need those servers to be 100% isolated. So its more of a matter of finding the right hosting solution that lets us provide some unique, different token or key to access individual servers under the account

Tim

11/3/23, 7:47 AM

Max, I think maybe you need to reconsider that solution architecture. I've been a solution architect for enough years I've lost count, I wouldn't implement a solution with one server per client without a really, really, really good reason that I couldn't get around.

Max Hudson

11/4/23, 11:37 PM

Thanks @Tim - I'd really rather not and definitely didn't start going down the path lightly. So far I haven't seen a way around it, but hopefully you can explain how to do it with AWS Secrets Manager + CMK

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: System architecture for storing sensitive data separately without single point of access

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.