1

We are building something like specific blogging social platform. Architecture was originally intended as to have:

  • single page application: all gui, rendered in the browser on the client
  • frontend: mainly proxy layer, api for that SPA, accessible from the internet
  • backend: not accessible from internet, just 443 port opened for frontend. Backend would have access to all the other systems (database, 3rd party systems, etc.)

Since we are limited on time and budget, we are thinking to simplify it as to go only with SPA + API at the beginning. API would be publicly accessible on 443 port and has open connection to all the remaining systems, althought the remaining systems would be in private network.

Is this model acceptable from the security point of view?

More specific variants:

A./ API connects directly to sensitive storage (db with user info)

B./ API has access to sensitive storages only via dedicated microservices, that exposes api that requires valid auth token and allow access only to matched user's account.

Thanks.

ooouuiii
  • 389
  • 2
  • 6

1 Answers1

2

It depends on the security features you have planned to implement in the proxy layer. From your description it sounds like a more or less transparent facade pattern, which wouldn't add too much in regard to security anyway. But I might be wrong, so let's dig deeper.

What are typical security features on such a proxy layer:

  • Only exposing a defined set of API endpoints
  • Implementing a rule-based application level firewall
  • Implementing centralized security monitoring
  • TLS offloading (which might protect against certain DoS attacks)
  • Injecting security features (e.g. authentication & authorization)
  • Protocol translation

Please note that this is not a comprehensive list but just some examples. What you really need depends on your actual threat model.

If you have planned to implement any security feature on the proxy layer that you are not going to or simply cannot implement in the new architecture, you will have to go through a risk acceptance process. Which threats would those mechanisms have addressed and are now left without mitigation?

No random person on the internet can decide if the residual risk of missing out on a specific security mechanism fits the risk appetite of your company. The real question you must ask yourself is not "is pattern A better than pattern B", but "which security mechanisms am I actually missing when implementing pattern B instead of pattern A and how does this influence my risk landscape".

Demento
  • 7,249
  • 5
  • 36
  • 45
  • Thanks for such a great answer! I exactly needed different perspective over the problem. I think the biggest difference is, if attacker gain access to the api server and it would be directly connected to the storages, attacker might get direct acccess to the storage. We will e. g. limit the ip address white list to connect to the api server, but I am not sure, wheter api server with direct (non microservice in middle) access to sensitive data is just security nightmare from the beginning. – ooouuiii Aug 12 '20 at 12:10
  • At the second thought, simple http proxy, that is publicly accessible and redirects to the internal network has no working overhead and solves the problem of getting all access after breaching the first layer. This might be our best initial fit. Thanks again. – ooouuiii Aug 12 '20 at 12:29