使用trigger VPD 限制Toad 等的访问权限

PURPOSE

This bulletin explains how to prohibit users from connecting to a database when using predefined applications, thus accessing the application tables directly
with (third party) tools such as ODBC / JDBC clients, TOAD or even Sql*Plus.

NOTE: In the images and/or the document content below, the user information and data used represents fictitious data from the Oracle sample schema(s) or Public Documentation delivered with an Oracle database product. Any similarity to actual persons, living or dead, is purely coincidental and not intended in any manner.

SCOPE

DBAs who have to secure access to the database data through different applications.

WARNING : You basically have no control over the client and hence everything
that comes from the client cannot be trusted. The methods described here may therefore
not be suitable to enforce a full security. Regard it as implementing business rules
rather than a fully secure method of enforcing them. Real security can and must be
enforced on the database only.

Basically the issue is that the database can authenticate users only, not client applications.

This article provides a specific example banning TOAD for NON DBA users.

DETAILS

Enforce the security on the database
------------------------------------

1. If your end users do not have SELECT and DML privileges granted to the
application tables but only through designated PL/SQL packages that they have
been granted execute rights, the risk of the use of ad hoc tools is already
lower.
2. If in addition to that, the roles are only set inside those PL/SQL packages
(application roles), there is nothing that can be done outside the scope of
your application.

Please refer to the topic 'Enforcing Application Security' in the book :
Application Developer's Guide - Fundamentals
Chapter 'Implementing Application Security Policies'
for a discussion on 'Use of Ad Hoc Tools a Potential Security Problem'

Different Methods to Prohibit the Use of Specific Tools or Applications
-----------------------------------------------------------------------

1. Sql*PLus: product_user_profile
=====================

The SQL*Plus client supports the product user profile:
to restrict access from SQL*Plus, disable the INSERT, UPDATE and DELETE
statements by inserting rows in the product_user_profile table.
Refer note:2181.1

Although the API is fully documented, third party client tools do usually not
support it so it is a weak security mechanism.

2. Use AFTER LOGON event trigger to check at connection time which program (tool) is used to connect to the database
===========================================================================

The PROGRAM column in V$SESSION can be used to discriminate between allowed
and disallowed tools, if appropriately set.

Refer bug:1237128 where older client installs did not populate the PROGRAM
column. (If you still have 8.0.6 on NT/WIN2K clients, install patch 1913574)
Refer note:271583.1 for more information on this problem.

Script to create the trigger under SYS user to forbid access by TOAD:

create or replace trigger ban_toad after logon on database
declare
v_sid number;
v_isdba varchar2(10);
v_program varchar2(48);
begin
execute immediate
'select distinct sid from sys.v_$mystat' into v_sid;
execute immediate
'select program from sys.v_$session where sid = :b1'
into v_program using v_sid;
select sys_context('userenv','ISDBA') into v_isdba from dual;
if upper(v_program) = 'TOAD.EXE' and v_isdba = 'FALSE' then
raise_application_error
(-20001,'TOAD Access for non DBA users restricted',true);
end if;
end;
/

Example
 

SQL> conn user1/xxxxx
ERROR:
ORA-00604: error occurred at recursive SQL level 1
ORA-20001: TOAD Access for non DBA users restricted
ORA-06512: at line 13

Warning: You are no longer connected to ORACLE.

Note that TOAD populates the MODULE column of V$SESSION :

SQL> select username, module from v$session where upper(program) = 'TOAD.EXE';

USERNAME MODULE
------------------------------ ---------------------------------------
SYSTEM TOAD 8.0.0.47

However, these are only populated after the logon trigger fires. It cannot
be used inside the trigger but later in V$SESSION to detect rogue clients.

Script to create the trigger under SYS user to forbid access by SQL*Plus:

CREATE OR REPLACE TRIGGER on_logon
AFTER LOGON
ON DATABASE
DECLARE
--Declare a cursor to find out the program
--the user is connecting with.
CURSOR user_prog IS
SELECT program FROM v$session
WHERE audsid=sys_context('USERENV','SESSIONID');

--Assign the cursor to a PL/SQL record.
user_rec user_prog%ROWTYPE;
BEGIN
OPEN user_prog;
FETCH user_prog INTO user_rec;
IF user_rec.program IN ('sqlplus.exe')
THEN
RAISE_APPLICATION_ERROR(-20001, 'You are not allowed to login');
END IF;
CLOSE user_prog;
END;
/

Example

SQL> connect test/xxxxx
ERROR:
ORA-00604: error occurred at recursive SQL level 1
ORA-20001: You are not allowed to login
ORA-06512: at line 16

Warning: You are no longer connected to ORACLE.

3. Use VPD for further restrict access to application tables
====================================

Expanding the example banning TOAD access, you can protect the important
application tables by checking the MODULE attribute from the sys_context
namespace, but only in Oracle Database 10g:

create or replace function no_toad_access (schema in varchar2,
object in varchar2)
return varchar2
as
begin
return
'upper(substr(sys_context(''userenv'',''module''),1,4))<>''TOAD''';
end;
/

Example

USER1.EMP is the table to be protected. Add a policy like:

begin
dbms_rls.add_policy
(OBJECT_SCHEMA =>; 'USER1',
OBJECT_NAME => 'EMP',
POLICY_NAME => 'BAN_TOAD',
FUNCTION_SCHEMA => 'SYS',
POLICY_FUNCTION => 'NO_TOAD_ACCESS',
statement_types => 'select,insert,delete,update' ,
UPDATE_CHECK => TRUE,
ENABLE => TRUE,
STATIC_POLICY => FALSE);
end;
/

With this in place, nobody can select rows from USER1.EMP with TOAD.
DBAs still have access thanks to the EXEMPT ACCESS POLICY system privilege.

More attributes can be used: refer Note:120797.1 'How to Determine Client IP-address,Language & Territory and Username for Current Session'

Disclaimer

This scripts and example code in this document are provided for educational purposes only and not
supported by Oracle Support Services. They have been tested internally, however, and work as
documented. We do not guarantee that they will work for you, so be sure to test them in your environment before relying on them.

----DDL log

SQL> create table ddl_log(ora1 varchar2(30));
 
Table created.
 
SQL> CREATE OR REPLACE TRIGGER ddl_trigger
BEFORE CREATE OR ALTER OR DROP ON DATABASE
BEGIN
    INSERT INTO ddl_log
    SELECT ora_sysevent FROM dual;
END;
/
  2    3    4    5    6    7
Trigger created.
 
SQL> BEGIN
DBMS_FGA.ADD_POLICY (
  2    3     object_schema      =>  'a',
  4     object_name        =>  'ddl_log',
  5     policy_name        =>  'policy1',
  6     enable             =>   TRUE,
  7     statement_types    =>  'INSERT, UPDATE, DELETE, SELECT',
  8     audit_trail        =>   DBMS_FGA.DB);
  9  end;
 10  /
 
PL/SQL procedure successfully completed.
 
SQL> conn b/b
Connected.
SQL> create table t1(id number);
create table t1(id number)-

----正常不会报错，
*
ERROR at line 1:
ORA-604: error occurred at recursive SQL level 1
ORA-28133: full table access is restricted by fine-grained security