Results 1 to 11 of 11
  1. #1
    Join Date
    Oct 2004
    Posts
    4

    Exclamation Unanswered: Oracle Security Concern

    Oracle Security Concern

    I have a concern about Oracle security responsibilities and roles this is my problem:

    If I have a DBA that is using the sys and sysadmin account and the DBA has access to everything as he is using this accounts. I know that is possible to create a user ID with DBA functions and to create another account with security functions that this person is going to review audit log in order to ensure authorize access and changes are performed in the DB in a controlled manner.

    Problem 1: If the DBA is the owner of the accounts sys and sysadmin he could delete the audit logs or just to disable the audit log function.

    Problem 2: the DBA is also the owner of user Root so if the Audit Log are kept in the Operating system level, he could also modify the files.

    Problem 3: There is not USER ID for DBA without audit trail function created in Oracle and Security User ID with audit trail function does not exist.

    So, is there any thing that I could segregate in Oracle DB the security function from the DBA function in order to have a better control of the security at the DB level.

  2. #2
    Join Date
    Jun 2004
    Posts
    796
    Provided Answers: 1
    By definition, a DBA administers the database. In order to do this he must have access to everything, otherwise he cannot do his job properly. Are you saying that you don't trust the DBA?

    However, if you wish to restrict his actions you could try changing the passwords for the SYS, SYSTEM, & ROOT accounts & then don't tell him what they are; set up an user account for the DBA & grant him the SYSDBA privilege.

    There is an ORACLE audit trail function; this can be set at whatever level you wish (i.e. all users logging on & off, specific users doing specific actions, actions taken on specific tables etc etc etc).
    90% of users' problems can be resolved by punching them - the other 10% by switching off their PCs.

  3. #3
    Join Date
    Oct 2004
    Posts
    4

    SYSDBA privilege.

    If a define a new user for the DBA with SYSDBA privilege role, is there any posibility that I can restrict the DBA for change, create or view the audit trail function.

    Thanks

  4. #4
    Join Date
    Sep 2002
    Location
    UK
    Posts
    5,171
    Provided Answers: 1
    Quote Originally Posted by gallet2004
    Problem 2: the DBA is also the owner of user Root so if the Audit Log are kept in the Operating system level, he could also modify the files.
    This seems to be the clincher, doesn't it? The obvious solution is that the DBA should not be the owner of user Root.

  5. #5
    Join Date
    Oct 2004
    Posts
    4
    Yes this is true, the DBA should not have user Root at the Operating system level. But what happen if he is the owner of user SYS and SYSADMIN at Oracle DB level. He could disable the audit function and you could not log the events.

    So is there any posibility that you could give to the DBA roles like for example to copy the SYS or SYSADMIN roles into a NEW role for the DBA and DISABLE the function relate to AUDIT TRAIL. So he could not do anything relate to AUDIT TRAIL Functions.

  6. #6
    Join Date
    Jun 2004
    Posts
    796
    Provided Answers: 1
    If you set the following initialization parameter:

    audit_sys_operations = true

    then you can audit ALL actions taken by anyone with the SYSDBA (or SYSOPER) privilege. The activity is logged to an operating system audit trail, not a database audit trail, so the DBA will not be able to tamper with it from within the database. Then all you have to do is to ensure that the DBA doesn't have enough privileges to tamper with it at the OS level.

    By default, the logging-on action of users with SYSDBA or SYSOPER privilege is audited: look for the audit file in the $OracleHome/rdbms/audit directory. or if running Windows then look in Admin Tools/Event Viewer/Application Log.
    Last edited by cis_groupie; 10-27-04 at 09:36.
    90% of users' problems can be resolved by punching them - the other 10% by switching off their PCs.

  7. #7
    Join Date
    Oct 2004
    Posts
    4
    This would be great. But How about if the SYSDBA or SYSOPER can modify the AUDIT TRAIL FEATURE and can just turn off and turn on and so. Shouldn't be the rigth thing to just disable the role to access this function to the SYSDBA or SYSOPER.

    Thanks

  8. #8
    Join Date
    Jun 2004
    Posts
    796
    Provided Answers: 1
    I'm not sure if you can do what you're asking (at this point, lots of posts come flooding in to prove me wrong!).

    You can create a trigger to report any action on the audit tables but the DBA could just as easily disable the trigger.

    You could consider not granting SYSDBA to the DBA - but then he would effectively be only as powerful as the other users, which means his ability to do his job would be restricted.

    I think you need to ask yourself what exactly it is you're getting at - you seem to be saying "You're the DBA but we don't trust you to be the DBA". As I said at the start, there has to be trust between the database's owner & the DBA, as the DBA must be able, by definition of his title, to administer the database. If the trust is not there then that person shouldn't be the DBA.

    If I were you I would be tempted to change the passwords, enable auditing for SYSDBA, and then check the logs & audit trails every so often to ensure that they're 'complete' OR get a DBA that you trust.

    BTW, who holds the ROOT password? Can they be trusted?!?
    90% of users' problems can be resolved by punching them - the other 10% by switching off their PCs.

  9. #9
    Join Date
    Jul 2003
    Posts
    2,296
    that is why you do background checks on your employees. this way you have at least a baseline of trust to start with.

    one last thing, I believe you can assign seperate OS level accounts and then
    monitor every command that account issues (in Unix anyways).
    - The_Duck
    you can lead someone to something but they will never learn anything ...

  10. #10
    Join Date
    Jun 2004
    Posts
    796
    Provided Answers: 1
    The_Duck, Just out of interest...

    I've never used Oracle on Unix so my knowledge is limited to the text books - Is what you've just said the same as, or in addition to, the "audit_sys_operations = true" parameter?
    90% of users' problems can be resolved by punching them - the other 10% by switching off their PCs.

  11. #11
    Join Date
    Jul 2003
    Posts
    2,296
    Quote Originally Posted by cis_groupie
    Is what you've just said the same as, or in addition to, the "audit_sys_operations = true" parameter?
    No, what I stated had to do with auditing what a user does on a Unix machine. You can monitor/log all commands a user enters.

    This can be very handy especially when you create a new account for a
    new DBA hire. You can then check the log daily to make sure they are not
    trying to do things or go places they shouldn't be.

    I read it somewhere (maybe my Unix-DBA quick Reference Guide?).
    - The_Duck
    you can lead someone to something but they will never learn anything ...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •