相信很多DBA会在系统中来个LOGON_AUDIT,目的就是避免某些未经过授权的机器登陆了数据库.

这事在我们这也有.为了防止从办公网络试用生产账号登陆生产主机非法获取用户信息(因为我们的生产账号是不作审计的,个人账号作审计,因此要避免生产账号从办公网络登陆主机),我们写了个LOGON_AUDIT的触发器,如下:

CREATE OR REPLACE TRIGGER sys.LOGON_AUDIT
AFTER LOGON ON DATABASE
declare
  lv_user   varchar2(100);
  lv_host   varchar2(100);
  lv_schema varchar2(100);
  lv_suser  varchar2(100);
  lv_ip varchar2(100);
BEGIN
  select sys_context(‘USERENV’, ‘HOST’),
         sys_context(‘USERENV’, ‘CURRENT_USER’),
         sys_context(‘USERENV’, ‘CURRENT_SCHEMA’),
         sys_context(‘USERENV’, ‘SESSION_USER’),
         sys_context(‘USERENV’, ‘IP_ADDRESS’)
    into lv_host, lv_user, lv_schema, lv_suser, lv_ip
    from dual;

  if lv_suser = ‘USERNAME’ then
    if substr(lv_ip, 1, in (‘xx.xx.xx’)
       or lv_ip is null
    then
       null ;
    else
      RAISE_APPLICATION_ERROR(-20001, ‘CONNECTIION REFUSED’||lv_ip);
    end if;
  end if;
END;
测试的时候,通过,可是在正式使用中,却发现有的生产主机没有办法拒绝办公网络的登陆.那就查问题呗.

查来查去,发现似乎应该是权限的问题.在检查,发现凡是不能拒绝办公网络登陆的数据库用户有一个IMP_FULL_DATABASE的角色.这个角色的权限非常的高,仔细检查这个角色的权限,发现其中有一个权限为:ADMINISTER DATABASE TRIGGER,将这个权限从用户上revoke后,登陆就会被拒绝,如果将这个权限授予用户,就会避开系统的LOGON_AUDIT触发器,能继续登陆,问题是找到了,啥时候能重新授权列,只能等待,慢慢的等到系统上线或者例行维护的时候了,这个权限的重新授予风险还是很高的.不过问题找到了就ok.



5 Comments to “数据库用户避开了LOGON_AUDIT触发器”

1. yumianfeilong — March 31, 2008 @ 4:10 pm
   

   权限的重新授予风险还是很高的?
   why?

2. David.Guo — March 31, 2008 @ 4:33 pm
   

   to yumianfeilong
   因为那个用户现在有了太高的权限,都是一些系统权限了
   而每个node平均5k的在线,2 node的系统
   在线重新授权,只要有一点问题,遗漏了任何该有的没有授予,大家就吃不了兜着走,所以还是等上线或者例行停机会比较安全,你觉得列.

   比如,一个用户原来有dba的角色,现在要把dba的角色回收,那么,对于dba中拥有的一些权限,你可能要单独给这个用户授予,因为有些权限是必须的,如果这个权限没有和应用充分确认过,直接收回dba,然后重新授予权限,可能就会导致一些应用由于权限的问题报错,不是吗.

3. d.c.b.a — April 2, 2008 @ 12:57 pm
   

   让他们用最小权限生存.

4. David.Guo — April 2, 2008 @ 4:35 pm
   

   to dcba
   正有如此想法,但是系统已经运行很久了
   万一少了那个权限,系统挂了也蛮麻烦的

5. Flybean — April 7, 2008 @ 2:43 pm
   

   权限一旦放开了,再要收回来,是比较麻烦.

Write a comment

You need tologin.