Are there security-issues with a read-only-account on Oracle-DBs

oracleread-only-databaseSecurity

I am currently working as IT-maintenance-guy for a classic MVC-system(oracle-db/jboss) at public sector. The newest feature should be the shutdown of my oracle-db-readOnly-Account cause of "security reasons" (<– Yes, it is not any more specific than that). I tried to some investigation on what that security threats might be, but i ended up finding no argument suiting my case.

My question is:
Can a readOnly-Access to an Oracle-Database cause any serious security issues?
I am looking for arguments that i can toss at the decision-maker that there is no threat coming from me having a readOnly-Account!

Additional information:

I am also inside the house-LAN (behind exterior firewall)
I am a learned SQL-user.
I don't store data on my local machine and i have no intention of selling/leaking any data. Beside the fact that the data is not the slightest bit intresting for any outsider 😉

Thanks in advance for any good ideas/arguments/issues/hints!!

Best Answer

Yes, there are.

every account puts load on the server and has the potential to bring it down by overloading it with silly queries or sometimes just bad luck.
more and more important: privacy issues. When a company leaks data they can get serious fines.
company secrets can be stored in the database. Leaking them does not help their case.

control and audits are getting more and more important.

A solution can be to have a copy system in place that generates an adhoc query database that is de-personified enough so privacy concerns can be remedied. It also alleviates the production host from the load caused by the research queries.

A controlled reporting tool can also be helpful, I just don't see how that mitigates privacy concerns other than having predefined reports that just don't show personal data.

Related Solutions

Sql-server – Security permission to only read SSAS Cube with Excel

In order for a specific role to have permissions over a cube data you have to specifically grant cube permissions to that role. That can be done using the Cube tab in the role properties page: in SSAS

-> Databases -> Your db -> Roles -> your specific role -> Cubes tab.

You can assign specific permissions for:

Access - None, Read, or ReadWrite
LocalCube/DrillthroughAccess - None, Drillthrough/Drillthrough and Local Cube
Process

Same for dimensions and their data and specific cell data. You can find further info about cube permissions in the following articles:

Jobs view is not visible to read-only account users

As @Jeffrey pointed out, ALL_* view is not useful in your case. You should use DBA_* views because they show the records for all owners of the job objects.

The following sequence works just fine for me:

$ sqlplus /nolog

SQL> connect / as sysdba
Connected.

SQL> select distinct owner from dba_scheduler_job_run_details;

OWNER
------------------------------
EXFSYS
SPONGEBOB
SYS

SQL> create or replace view sys.jcaf as
  2  select * from dba_scheduler_job_run_details
  3  where owner = 'EXFSYS';    
View created.

SQL> grant select on sys.jcaf to spongebob;    
Grant succeeded.

SQL> create public synonym jcaf_v for sys.jcaf;    
Synonym created.

SQL> connect spongebob/passwd    
Connected.

SQL> select distinct owner from jcaf_v;

OWNER
------------------------------
EXFSYS

Best Answer

Related Solutions

Sql-server – Security permission to only read SSAS Cube with Excel

Jobs view is not visible to read-only account users

Related Question