0

We have very few developers and the ask from management is insane (computer vision, AI, IoT, etc.). Management wants to split the production database which uses Oracle Apex because the Apex application will be on the public internet and therefore security is an issue. Is a separate database more secure than using the same database and a separate schema when using the Oracle database? I hate REST and all the complications like authentication that comes with it, so I would much rather be on the same database and just do a straight SQL select. Can I just grant select on specific tables between two schemas and thereby keep sensitive financial data equally secure as when having it on a separate database and sharing data using REST or a slow database link?

3

Management wants to split the production database which uses Oracle Apex because the Apex application will be on the public internet and therefore security is an issue.

If Management don't want the database server that hosts the Apex application on the "public internet" then that's what they want. That database server will move to somewhere "inside" the Firewall.

Is a separate database more secure than using the same database and a separate schema when using the Oracle database?

From an Information Security stand-point? Almost certainly.

Machines tend to be compromised, not Applications.
If this database server were to be compromised then the attacker would presumably target the root account and thereby gain access to any other account on the machine. If, like most other DBAs, you've allowed O/S authentication for your "oracle" account, then the whole database is vulnerable.

From a cross-application perspective? Not if you've set up your security model properly.

You can (and should) set up Roles that grant specific permissions on specific objects and grant these Roles to the Application Accounts that need to use them. In that way, Application A can access the tables in Schema B that it needs to use but nothing more.

REST and other API-based strategies move this into the Application layer, where Developers are move "comfortable", but even these still need access to database objects so the creation/granting of Roles still applies.

| improve this answer | |
2

A few thoughts:

  • If I read this right, you're talking about separate schemas for your test and production databases, vs. physically separate test and production databases. If this is what you're describing, then management is completely correct, not "insane". In this case, you must keep them separate; they shouldn't even exist on the same server. Development and production generally operate at completely different security levels, and doing both on the same system, let alone the same database, can seriously compromise your production security. Also, you don't want test and development activity to impact production performance or availability, and you don't want developers anywhere near production data as a general rule.

  • Whether cohabitating with development is an issue or not, no database with "sensitive financial data" should ever be placed directly on the public internet. A typical, relatively secure configuration would have only the web server on the public internet, and the application server and database behind multiple firewalls. It won't matter if you have a separate database if the physical server is placed somewhere insecure by definition.

  • All a database instance is is a set of files and running processes. Multiple databases would still be serviced by the same network listener process, the same OS, and have all of the same external protections, so not really more secure from that standpoint. More databases means more running processes, which means more CPU and memory requirements for the system.

  • Someone has to be able to log in to the database, which means you'll have to deal with authentication and security between users/schemas no matter what you do. If you're letting anyone (including you) log in directly as the account that owns the tables and data, you might as well give up and go home now.

  • If you're really dealing with "sensitive financial data" then there's a good chance that you are legally required to provide certain protections of that data, such as not putting it on the public internet, not cohabitating development and production, requiring certain types of authentication and auditing, disaster recovery, etc. You might want to make sure what the statutory requirements for your system are before doing anything rash; your corporate officers with fiduciary responsibility could potentially even face criminal proceedings if you don't get it right and something happens to the data.

| improve this answer | |
-1

I am also in a very small team, are these aspects of the same production system? Why is it that they want you to keep them separate?

If security is an issue I would not want to grant select on the other schema as that allows anyone connected to the database to read anything in the other schema, you might want to look into Oracle Rest Data Services, which also handles REST authentication etc for you. It also allows only certain SQL statements to be run. I'm not sure how familiar you are with it, but it's been an absolute lifesaver for me. Let's talk in the comments :)

In short, yes another database should make it more secure. Check out ORDS.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.