If I wanted to I could have my computer running a VPS with 13 GB of ram aloted and close all ports with outbound requests only. I could then use that Virtual machine to run the wallets. No ports being forwarded or any direct communications from anything. The servers decide their job based off of the Mysql Database they are connected to through a virtual network that is hub and spoke managed.
Its actually a little more complicated because if your webserver has access to the MYSQL db, then I could hypothetically just go and make changes in Mysql and take all your funds. You need to think how to ensure that even if I get access to the Mysql DB connected to the webserver, I shouldn't be able to cause any damage financially.
How could you make changes with a SQL user that has no write access to any of the finance tables nor any direct access to methods manipulating balances? If you were to read the description on the front page it clearly states that the SQL gives no permissions to the front-end except to view user information and to view balance information. IT can submit a request to be processed by the back end server that is structured like
create/trade/5/1000/100/5 and is signed and encrypted. Even if you managed to figure out the signing and encryption the backend servers do another check to verify the trade is even allowed to be created.
The servers all are on a closed network with communication enabled ONLY to the SQL database. Each server has its own SQL user with its own permission.
To even prove that you lacked the true effort of reading here is an excerpt from the main page:
[The webserver must only be capable of reading information and relaying commands without having any
direct access or direct command of the wallets. Any transactions believed to be taking place on the website are
in fact not taking place on the website. The users input is checked and their balances verified; Then the
system puts forth a structured request that is then processed by the Wallets server.]
Trust me I read but the fact is that if there is no way to write something in a db, then how will the user modify data.
You cannot expect to provide manual intervention to each and every data entry. Again, if someone hacks the server, the purpose wont be to perform trades but to perform withdrawals. How have you designed your system so that you know for sure that the incoming request is true and is also automated. You dont need to tell everyone but you do need to think.
Also, for this argument, assume that I have hacked the webserver and I exactly know your db username and password and even if the db server is on an internal network, I can still access it using the webserver ssh. Moreover, most probably if I have SSH access to the webserver, I will exactly know your DB encryption passwords.