how to design secure database for Mobile recharge codes

Question

Suppose I want to keep millions of recharge codes into a separate database(named A) having a table . I want to design another database(named B) which will be used by a web application. I want to keep my database A separate and as secure as it can be, preferably not exposed to the network. so that nobody could get access/hack to the huge sensitive data.

But I also have to populate one table of database B with the codes from table of Database A as needed or requested from web application.

I am using Mysql DB and Apache Tomcat as web server .

Can you please suggest me any best and secure way of designing the database keeping in mind that.. 1) The safety of codes in database A are the priority. 2) the tables will contain millions of rows so quick response is also requirement.

Answer 1

I'm adding this as an answer because it is too long for a comment.

I think this is more about app design and layering than about the database design as such. In terms of DB design, you just need the tables to have indexes that use all the keys you will have. The db-access will be sub-second.

In terms of app design, I suppose your app will know when to look at table-B and when it has to retrieve from table-A.

So, the key issue is: how to access A. The simplest way would be for the app to connect to A, and read it via SQL. The problem with this is that a hacker who is on your app server could then see your connection details. You could try to obscure the connection details from app-server to A. This would be "security through obscurity" and would be something, but would not stop a good hacker.

If you're serious about control, you could have an app running on A. You can block all ways for apps from outside A to access the database on A, leaving the app on A as the sole point of access.

By it very uniqueness, the app could provide another level of obscurity. For instance, the app could insist on knowing the customer-id for whom the code is being requested, and could check this against some info (even on B). But, there are better reasons to use one...

The app on B could

• impose controls: e.g. only 1000 codes given out per hour
• send alerts: e.g. email an operator if more than 500 codes have been requested in the hour