A database auditor asked me for some quick help answering the question, "Who has DBA privs?" Somebody from the client's dba team did a simple:
This is a hierarchical query problem. Traditionally, hierarchical queries are used to answer questions like, "Who is under the CIO?" Direct reports are easy...but a person who reports to a person who reports to the CIO is more difficult...the more layers, the more difficult it is.
The first time I had to do this was on a Sql Server ERP I was supporting...I had to write a query that went 6 levels deep...it was complex and ended up being about 2 pages long. To do on Sql Server you have to find the root node and then all the leaf nodes for all the levels of the tree. Quite the pain. About a year later we migrated that ERP to Oracle...the new statement in Oracle that was logically equivalent was just a few lines. This is because Oracle's SQL extensions, "CONNECT BY PRIOR" and "START WITH" make this relatively easy.
The request from the auditor was to find all the people who have sysdba, sysoper or dba privs, no matter how they got them. (note: The statement below will display people twice if they're granted sysdba/sysoper AND a deep dba role...the auditor was ok with that)
Hopefully this will help some of you tighten up your db security and aid in your hierarchical problems.
select * from dba_role_privs where granted_role='DBA'
That's ok...but some people were still demonstrating DBA abilities who didn't show up on that list. If somebody is granted a role that's been granted dba...or a role that's been granted a role that's been granted dba (etc) this statement would miss them. This can go on infinitely deep, and it can be a way to hide dba privs from auditors if its buried deeper than the person searching for the priv is willing to check.This is a hierarchical query problem. Traditionally, hierarchical queries are used to answer questions like, "Who is under the CIO?" Direct reports are easy...but a person who reports to a person who reports to the CIO is more difficult...the more layers, the more difficult it is.
The first time I had to do this was on a Sql Server ERP I was supporting...I had to write a query that went 6 levels deep...it was complex and ended up being about 2 pages long. To do on Sql Server you have to find the root node and then all the leaf nodes for all the levels of the tree. Quite the pain. About a year later we migrated that ERP to Oracle...the new statement in Oracle that was logically equivalent was just a few lines. This is because Oracle's SQL extensions, "CONNECT BY PRIOR" and "START WITH" make this relatively easy.
The request from the auditor was to find all the people who have sysdba, sysoper or dba privs, no matter how they got them. (note: The statement below will display people twice if they're granted sysdba/sysoper AND a deep dba role...the auditor was ok with that)
select username, 1 level_deep from V$PWFILE_USERS
union
select grantee, max(level_deep) from (
select distinct level level_deep, grantee, granted_role
from dba_role_privs
start with granted_role='DBA'
connect by prior grantee=granted_role
) where grantee in (select username from dba_users)
group by grantee
order by 1;
With variations of this statement, he was able to find how some people who weren't directly granted DBA were able to use DBA privs. He even found one guy who had a dba role that was granted 8 levels deep...(ie: he was granted a role that was granted a role (repeat 7 times) that was granted DBA!) That would never have shown up on older audit reports.union
select grantee, max(level_deep) from (
select distinct level level_deep, grantee, granted_role
from dba_role_privs
start with granted_role='DBA'
connect by prior grantee=granted_role
) where grantee in (select username from dba_users)
group by grantee
order by 1;
Hopefully this will help some of you tighten up your db security and aid in your hierarchical problems.
Công ty nhận nhập khẩu hàng từ hàn quốc về việt nam chi phí thấp
ReplyDeleteĐơn vị chuyên lấy hàng từ hàn quốc về việt nam giá thấp
Đơn vị nhận order phụ kiện quảng châu giá rẻ
There are many situations where ADMIN wanted to revoke DBA privileges granted to the user. This is the best way to filter out users having dba privileges in Oracle
ReplyDelete