4

I am developing a web application that will expose a public API to the world, but will store very, very sensitive personal, private data. Having the content hacked would be fatal.

I will be using the following technologies:

  • REST (over HTTPS)
  • Apache server at the backend
  • PostgreSQL database

I have come up with an idea (I thought of it myself, so it may have vulnerabilities that security experts on here may spot).

The components of my secure environment are as follows:

  1. Machine A: Front (public) facing server on a dedicated machine (i). This machine has firewall rules to only allow TCP connections via port 443 (HTTPS) (ii). Apache configuration only accepts certain regex patterns of published API (iii). Apache forwards request to server B, using an internal API mapping, and using a secret, non standard port

  2. Machine B: (i). This machine has been setup to only accept data from Machine A (ii). This is where the application logic and data exist (iii). Results sent back to Machine A, to send back to requester.

Can anyone improve on this setup (i.e. 'harden' or make it more secure)?

Improve this question
4
  • 1
    What about logical flaws in the API? What about users accessing data that belongs to other users through horizontal privilege issues? My concern would be that a system like this might take resources away from fixing more direct issues, due to the complexity involved.
    – Matthew
    Dec 10, 2015 at 13:34
  • 1
    @Matthew: It's interesting that you also, think the solution I proposed, is complex. What would be a simpler solution that provides protection against hacking for the sensitive, private data held on the server?
    – Homunculus Reticulli
    Dec 10, 2015 at 13:38
  • 1
    I'm generally concerned that you have "public API" and "sensitive personal, private data" in the same sentence! My general approach would be to harden the API itself, and run that on a hardened single server. This is down to reducing the number of moving parts - with 2 servers, you need to be sure that both are patched properly, have twice as many logs to monitor, and so on. If (A) gets compromised, an attacker can monitor data through it. If (B) gets compromised, they can grab the data directly. Either way, you need to know.
    – Matthew
    Dec 10, 2015 at 14:36
  • 2
    If you are going to post a question about how to protect extremely sensitive private data, you may need to be ready for people to treat "Having the content hacked would be fatal" literally. My advice is one I give often here: define your threat model. Who is going to attack you, how often, and how bad is it if they get the data. If you're going to literally be the victim in a homicide if the data is leaked, and the NSA themselves are going to attack your server, the bar for security is going to be mighty high... as in "do you even trust your OS?" How about your CPUs? Are they from China?
    – Cort Ammon
    Dec 11, 2015 at 4:28

4 Answers 4

Reset to default
5

Seek professional advice...seriously, if the data is as sensitive as you say and the consequences are truly fatal, it would be negligent to rely on advice from here upon which to base a solution.

Nobody can offer a reliable contextual answer because there is not enough information about the business requirement the solution is for. Some things that would need to be considered in order to determine an appropriate solution: the intended audience, what the data is, what it will be used for etc. these may open up alternative architectures that would provide more effective risk mitigation.

There will be aspects that are not referred to in your question...access control (multi-factor possibly), pseudo or real-world identity requirement (impacts registration), encryption of data.

If you are in Europe data protection legislation will apply...so there is a whole raft of pre-reqs before even collecting the data: conditions for processing, where the data can be processed, what it can be used for etc.

I know this is not a direct answer to your question, but I was running out of space in a comment...you may well have considered all of this, but I just wanted to make sure!

Improve this answer
1
  • 1
    Thanks very much for the insightful questions. I guess when asking questions about security, that's no time to be coy. Ok, I'm trying to build something similar to mint.com. So to answer your questions, the target audience is pretty much "anyone who wants to monitor their finances", the data is sensitive financial information: account numbers, transactions etc. Hope you can shed some more light now that I have provided additional details.
    – Homunculus Reticulli
    Dec 11, 2015 at 6:21
1

So basically, A is acting as a firewall for B, doing some additional validity checks.

How are machine A and B connected? Are there (or could there be) any other machines on that network? If there are, this split might not buy you much security wise. Make sure the connection is encrypted and secure machine B just as well as if it was connected directly to the internet.

Using regex to validate API calls strikes me as a bit strange, but you might be more likely to get away with a misconfigured service on B that way.

As a general note: this setup introduces additional complexity. Complex systems are more difficult to secure than simple ones. Is the data on B still safe if A has been compromised? If no, then you just increased the attack surface. Double check if you can get the same level of security using just a single machine.

Improve this answer
2
  • Those are good questions you raised. The machines are dedicated servers in a service providers server bank. I guess I can insist that the machines be directly connected to each other, and that there be no other machines on that "cable". Regarding your statement of it being a complex setup, how can I simplify the setup?. I generally like the idea of a "public facing" server, and keeping the "real data" behind a secure firewall, and not available to the public. I'd like to hear your viewpoint.
    – Homunculus Reticulli
    Dec 10, 2015 at 13:32
  • The idea of hiding sensitive data behind a public facing server definitely has its merits. As I said above, if a compromise of machine A makes it trivial to get to the data, then don't bother. If the data is still safe, then yes, it may actually make sense to have a two-machine setup. Use different network interfaces on machine A for public and local connections, it's a prerequisite for having no other machines on the cable.
    – tarleb
    Dec 10, 2015 at 13:48
1

We are talking about sensitive information here, financial info some more. It is very crucial for you to ensure that access to the database is strictly allowed to those who are authorized only. I can suggest at least you have to physically separate your machines/servers i.e. web, application and database servers and have a firewall in between. Data transferred between the servers should be encrypted, same goes to the data stored in the database server. Other than that, all basic securities should be in place e.g. IPS, IDS, SSL etc.

Improve this answer
-1

This sounds like a dmz type of setup. Basically if the information is fatal if lost, then i would suggest looking into physical security and 2FA/biometric/yubikey style setups. The thousands of dollars worth hardened skiff might be worth while, though you could spec one up using a standard safe.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .