How secure is this architecture?

Question

Hi,

I'm building a system that need to collect some user sensitive data via secured web connection, store it securely on the server for later automated decryption and reuse. System should also allow user to view some part of the secured data (e.g., *****ze) and/or change it completely via web. System should provide reasonable level of security.

I was thinking of the following infrastructure:

App (Web) Server 1

1. Web server with proper TLS support for secured web connections.

2. Use public-key algorithm (e.g. RSA) to encrypt entered user sensitive data and send it to App Server 2 via one-way outbound secured channel (e.g. ssh-2) without storing it anywhere on either App Server 1 or DB Server 1.

3. Use user-password-dependent symmetric-key algorithm to encrypt some part of the entered data (e.g. last few letters/digits) and store it on the DB Server 1 for later retrieval by App Server 1 during user web session.

4. Re-use step 2 for data modification by user via web.

DB Server 1

1. Store unsecured non-sensitive user data.
2. Store some part of the sensitive user data encrypted on App Server 1 (see step 3 above)

App Server 2

1. Do NOT EVER send anything TO App Server 1 or DB Server 1.
2. Receive encrypted user sensitive data from App Server 1 and store it in DB Server 2.
3. Retrieve encrypted user sensitive data from DB Server 2 according to the local schedules, decrypt it using private key (see App Server 1, step 2) stored locally on App Server 2 with proper key management.

DB Server 2

1. Store encrypted user sensitive data (see App Server 2, step 2)

If either App (Web) Server 1 or DB Server 1 or both are compromised then attacker will not be able to get any user sensitive data (either encrypted or not). All attacker will have is access to public-key and encryption algorithms which are well known anyway. Attacker will however be able to modify web-server to get currently logged users passwords in plaintext and decrypt part of user sensitive data stored in DB Server 1 (see App Server 1, step 3) which I don't consider as a big deal. Attacker will be able to (via code modification) also intercept user sensitive data entered by users via web during potential attack. Later I consider as a higher risk, but provided that it is hard (is it?) for attacker to modify code without someone noticing I guess I shouldn't worry much about it.

If App Server 2 and private key are compromised then attacker will have access to everything, but App Server 2 or DB Server 2 are not web facing so it shouldn't be a problem.

How secure is this architecture? Is my understanding of how encryption algorithms and secured protocols work correct?

Thank you!

Answer 1

So far so good. You are well on your way to a very secure architecture. There are other concerns, such as firewalls, password policies, logging, monitoring and alerting to consider, but everything you described so far is very solid. If the data is sensitive enough, consider a third party audit of your security.

Answer 2

I don't think I can give a proper response because I'm not sure the goal of your system is clear. While I appreciate you getting feedback on a design, it's a bit hard without a purpose.

I would suggest to you this though:

Strongly document and analyse your thread model first

You need to come up with a fixed hard-lined list of all possible attack scenarios. Local attackers, etc, who are you trying to protect against? You also say things like 'with proper key management'; yet this is one of the hardest things to do. So don't just assume you can get this right; fully plan out how you will do this, with specific linking to who it will prevent attacks by.

The reason you need to do a threat model, is that you will need to determine on what angles you will be vulnerable; because this will be the case.

I will also suggest that while the theory is good; in crypto implementation is also very critical. Do not just assume that you will do things correctly, you really need to take care as to where random numbers come from, and other such things.

I know this is a bit vague, but I do think that at least coming up with formal and strong threat model, will be very helpful for you.

Answer 3

I would not recommend using any form of public key to communicate from your web server to your app server. If you control both system just a regular secret system of encryption. You know the identity of your app server, so keeping the key secure is not an issue. If you ever need to change or update the secret key just do so manually to prevent it from leaking across a connection.

What I would be most careful about is direction of data transfer from your server in your DMZ, which should only be your webserver, to those boxes residing internally to your network. It is becoming increasingly common for legitimate domains to be compromised to distribute malware to visiting users. That is bad, but if the malware were to turn in ward to your network instead of only outward to your users then your business would be completely hosed.

I also did not see anything about preventing sql injection or system hardening/patching to prevent malware distribution. This should be your first and most important consideration. If security were important to you then you would be your architecture to be flexible to minor customizations of inter-server communication and frequent patching. Most websites, even major legitimate businesses, never fix their security holes even if they are compromised. You must be continually fixing security holes and changing things to prevent holes from arise if you wish to avoid being compromised in the first place.

To prevent becoming a malware distributor I would suggest making hard and fast rules upon how media is served that contains any sort of client-side scripting. Client-side scripting can be found in JavaScript, ActiveX, Flash, Acrobat, Silverlight, and other code or plugin that executes on the client system. Policies for serving that content must exist so that anomolous code fragments can be immediately identified. My recommendation is to NEVER embed client-side code directly into a browser, but always reference some external file. I would also suggest conslidating like minded media to give you better asset control and save you bandwidth, such as serving one large JavaScript file instead of 8 small ones. I would also recommend forcing all such media onto an external content distribution system that references your domain in its directory structure. That way media is not served from your servers directly and if it served from you directly you can quickly identify it as potentially malicious and necessittating a security review.