cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
gidyn
Contributor III

Segregating cloud regions by account

A CSP I'm familiar with deploys SaaS to multiple regions, on another CSP's IaaS/PaaS. Each region is isolated in its own I/PaaS account, leading to a lot of manual duplication, as any configuration or other operation in one region has to be duplicated across all the others. Some of this could perhaps be automated, but a lot of the work is ad-hoc, and strict security boundaries generally make it impossible for any automation to access multiple accounts (user accounts for the operators are not restricted).

 

The justification for this segregation is security - they want to restrict the potential damage in the event that a miscreant gains access to one of the accounts. This could come about through e.g. some catastrophic compromise of the SaaS, or if the miscreant is somehow able to authorise a new user or API key. In any case, this only makes sense when it is impossible for the same breach to be replicated by an attacker across other regions, or if they're expecting to detect the compromise and block it globally first.

 

The operations people are, needless to say, none to pleased with all of the tedious manual duplication. What do you think? Is this a valid threat model? Are the security benefits worth the operational cost?

6 Replies
denbesten
Community Champion

In my mind, the entire point behind SAAS is that things like this become "their problem".  

 

As a customer of the SAAS provider, is this "messiness" exposed to you?  If so, I can see three workarounds:

 

  1. Subscribe to their services in only one region and to require users in other regions to traverse multiple time-zones. 
  2. Write a script that accepts a command as an argument and then runs the command in each region. Those of us with a multi-domain AD forest are pretty used to this tactic. Of course, it means abandoning the GUI in preference for CLI.
  3. Pick another SAAS provider with an offering that better meets your needs.

 

gidyn
Contributor III

Clarification - I'm writing from the perspective of the SaaS provider, not a customer. This is completely transparent to customers.

tmekelburg1
Community Champion


@gidyn wrote:

The justification for this segregation is security - they want to restrict the potential damage in the event that a miscreant gains access to one of the accounts. This could come about through e.g. some catastrophic compromise of the SaaS, or if the miscreant is somehow able to authorise a new user or API key. In any case, this only makes sense when it is impossible for the same breach to be replicated by an attacker across other regions, or if they're expecting to detect the compromise and block it globally first.


Data segmentation due to different regional regulations came to my mind. Another reason would be to get government customers where one of the stipulations is, the data must stay within the country of origin regardless of data sensitivity.

 

TikToc would be an example of this. Keeping American data only in US datacenters and not allowing access from China.

gidyn
Contributor III


@tmekelburg1 wrote:


Data segmentation due to different regional regulations came to my mind. Another reason would be to get government customers where one of the stipulations is, the data must stay within the country of origin regardless of data sensitivity.

This doesn't require separate accounts, although that could form a guardrail. One account can hold a database for each region, and that region's deployment of the service will only access its own database.

It could be considered a guard rail though to prevent data accidentally leaking across regions.

tmekelburg1
Community Champion

@gidyn Yeah, I don't think you could say your data is properly segmented if there were accounts that could cross regional datacenter boundaries if that were one of the security goals. For the sake of easiness and cost, I would think the default would be to start with the ability to make sweeping changes on one dashboard, aka account, and then become more restrictive and expensive depending on customer needs and regulations.

 

It's a give and take with security vs. usability here. At least that's what it seems like to me.

gidyn
Contributor III


@tmekelburg1 wrote:

@gidyn Yeah, I don't think you could say your data is properly segmented if there were accounts that could cross regional datacenter boundaries if that were one of the security goals.


Except that ... separating the accounts doesn't actually do this. Each region has its own databases. The code can only connect to the databases that it has credentials for. Whether they're in the same account or not is immaterial. Perhaps this is very slightly reducing the chance of human error, other than that the only data segmentation that this achieves is security theatre.