Walid
You've asked variants of the same question several times now. The base
problem that we have replying is that the scope is far too general, and yet
your requirements will be specific. Security, like performance, is an
*application feature
*not, primarily, a database administration feature. Imagine for a moment
that the SCOTT schema actually is the database tier of your organisation's
HR application. Which people (job role and/or name) are allowed to run the
query below is an application design question, where they can run it from
(web, mobile phone, thick client, sqlplus, bash script) is an application
design question. How executions of the query are logged, and who can view,
modify and archive the logs is an application design question.
select
empno
, ename
, job
, sal
from empwhere
sal between 2000 and 3000 and job in ('DBA', 'MANAGER');
Now imagine that the query is against your sales data
select
custno
, cust_name
, sales_date
, sale
from saleswhere
sale between 2000 and 3000 and state in ('TX', 'CA');
The exact same questions as for the HR query apply, but the answers will
probably be very different. When the application designer has provided
answers to these questions, then you will have a better handle on how you
might implement specific solutions, for example they might say "Only
Managers from the HR group can query job and salary information for all
employees". In such a case you and they will need to find an appropriate
method to authenticate users, using access tokens that can be related to
their HR job role - this might be username and password, it might be an
LDAP authenticated session, it might involve identifying a workstation by
MAC address and so on. The technology used depends on the application
designer asking the right questions.
As for specific technologies that are available to you I'd give the
following advice.
You should definitely read the 2 day security guide, and then make a list
of items you will, or won't implement.
http://docs.oracle.com/database/121/TDPSG/toc.htm.
You should definitely read your organisations system security guide and
then make a list of items you won't implement and why, together with a list
of what you will implement and how.
You should definitely determine what legislation applies to your data use
and storage.
You should, in my view, read Arup Nanda's project lockdown OTN series
http://www.oracle.com/technetwork/articles/index-087388.html
You should look at the books and other references already provided in other
answers.
In all cases when you've matched the technology to the application design,
then the application designer, a business manager and your information
security folks should sign off on the risk.
You'll have noticed that all this is
- expensive
- time consuming
- complicated to document
- requires ongoing maintenance effort.
This is why most applications don't implement security at all well and,
quite often why people try to make it a technological rather than business
decision.
On Wed, Apr 8, 2015 at 10:49 AM, walid kaakati <dmarc-noreply@xxxxxxxxxxxxx>
wrote:
Hallo list,
I have rephrased my question :
By database auditing i Know who accessed the database, remains for me to
prevent unauthorized access to the database let us say by
hacking,programs... .
How i can do this ? any ideas that you implement in your production
databases.
Best Wishes
