Thông tin tài liệu
CHAPTER 21 • ORACLE8i DATABASE SECURITY
958
context package; user sign-on context package seems like a more appropriate name.)
The context area is an area of private memory that is unique to every session con-
nected to the database. You will create placeholders in this memory area to store some
values that are set at logon. Later in the process, you will read the context memory
area and retrieve these stored memory areas for use. This is an optional step. You
could define the context area every time the user accesses the object, but this
approach is faster, because you do these checks only once.
You place values into the context area by creating a package or function that is
called each time users log on to the database. For this project, you will store the user’s
assigned security level into a context variable whenever the user logs in. This way,
you can quickly retrieve this security value from the context area when you need it.
This saves multiple trips to the security table to look up the security ID each time you
need that value.
Before you can use a context namespace, you must first create the context name-
space, which needs to be done only once for each specific context area. The context
namespace is created using the CREATE CONTEXT command (or you can use CREATE
OR REPLACE CONTEXT, if you prefer). When you create the context namespace, you
define the package that will be used to set the values to be stored in the context
namespace. Typically, when you create the context, the associated package will not
have been created yet, and that’s okay. You will create that package next.
NOTE Creating the context namespace is similar to programming with a pointer. You
first create the pointer, and then you allocate memory to it. The same is true with a con-
text. You first create the context, and then the context setting package “allocates” what is
to be stored to the context. (Okay, so all comparisons have limitations!)
After you have created the context area, you will use the DBMS_SESSION.SET_
CONTEXT package to store a value in a context area. This package allows you to cre-
ate what amounts to variables and assign values to these variables. These variables
and their assigned values are then poked into memory for quick retrieval later. The
DBMS_SESSION.SET_CONTEXT procedure takes three parameters. Here is the proce-
dure definition:
PROCEDURE DBMS_SESSION.SET_CONTEXT
( NAMESPACE VARCHAR2,
ATTRIBUTE VARCHAR2,
VALUE VARCHAR2);
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
959
When you call the SET_CONTEXT procedure from your context setting package or
function, you simply pass it the name of the context you want to use, the name of
the context variable you wish to create, and the value you wish to store associated
with that variable.
When you create the application context package, this package will take one param-
eter, which is the username of the user who is signing onto the database. You use the
username to cross-reference with the TBL_USER_ID table columns USER_NAME and
SECURITY_LEVEL to determine what the proper security level setting for the user
should be. You then set a context variable called security_level to the correct security
level for the user. You will use a database logon trigger to call the package.
Listing 21.7 shows the creation of a context and then the creation of the context-
checking package.
Listing 21.7: Creating the Context and Context-Checking Package
Grant the required privilege to create the context.
CONNECT system/robert
GRANT CREATE ANY CONTEXT TO spy_owner;
GRANT DROP ANY CONTEXT TO spy_owner;
GRANT CREATE ANY TRIGGER TO spy_owner;
GRANT ADMINISTER DATABASE TRIGGER TO spy_owner;
Now, connect and create the context. We will reference the
currently nonexisting package pkg_spy_owner_context_01 as the
context-checking package. We will write this package next.
CONNECT spy_owner/spy_owner
Drop any preexisting context.
DROP CONTEXT spy_owner.cont_spy_owner_01;
Create the context. Note that we could have used CREATE OR
REPLACE instead.
CREATE CONTEXT cont_spy_owner_01
USING spy_owner.pkg_spy_owner_context_01;
Now, create the pkg_spy_owner_context_01 package header.
CREATE OR REPLACE package spy_owner.pkg_spy_owner_context_01
AUTHID DEFINER AS
PROCEDURE proc_get_spy_context(p_usern IN VARCHAR2);
END;
ENFORCING ROW-LEVEL SECURITY
Beyond Simple
Database Managment
PART
III
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 21 • ORACLE8i DATABASE SECURITY
960
/
Now, create the package body.
CREATE OR REPLACE PACKAGE BODY pkg_spy_owner_context_01
AS
PROCEDURE proc_get_spy_context(p_usern IN VARCHAR2)
IS
V_Spy_clearance NUMBER;
BEGIN
Now, take the p_usern, look it up in our
tbl_userid table and get the correct clearance
for this spy.
SELECT security_level
INTO v_spy_clearance
FROM spy_owner.tbl_user_id
WHERE user_name=p_usern;
These next two lines will store the username and the
user clearance level in the context for later use.
SYS.DBMS_SESSION.SET_CONTEXT(’cont_spy_owner_01’,’v_spy_clearance’,
v_spy_clearance);
SYS.DBMS_SESSION.SET_CONTEXT(’cont_spy_owner_01’,’spy_id’,p_usern);
END proc_get_spy_context;
END pkg_spy_owner_context_01;
/
NOTE Notice the use of the DROP CONTEXT command in the example. This command
will drop any existing context. To create a context, you must have the CREATE ANY CON-
TEXT privilege. To drop a context requires the DROP ANY CONTEXT privilege.
Keep in mind that setting the context, as done in Listing 21.7, and the actual
implementation of FGAC are two different things. You are only setting the context
area with the username and the clearance code because it will make the performance
of your security policy (which truly implements FGAC) better.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
961
Executing the Context Package at User Logon
Once the context-checking package is in place, you need to create a database logon
event trigger to call the application context package. It is the job of this trigger to fire
when the user logs in to the database. The user’s context area will be created, and
then the application context package will be executed, determining the security level
of the user.
To create this logon trigger, you use the built-in SQL function SYS_CONTEXT. This
function returns the value of a specific context variable to the calling program or SQL
statement. Oracle provides a built-in context namespace for each user session called
USERENV. You will use this built-in context namespace to get the username of the
user who is logging in to the database. You will then pass that username to the appli-
cation context-checking package. You will use the values stored in the context areas
shortly. Listing 21.8 shows the logon trigger.
Listing 21.8: Setting the Application Context with a Logon Trigger
CONNECT spy_owner/spy_owner
The logon trigger
CREATE OR REPLACE TRIGGER tr_db_logon_01
AFTER LOGON ON DATABASE
DECLARE
spy_id VARCHAR2(30);
BEGIN
spy_id:=sys_context(’USERENV’,’SESSION_USER’);
pkg_spy_owner_context_01.proc_get_spy_context(spy_id);
EXCEPTION
WHEN others THEN
NULL;
END;
/
Creating the Security Enforcement Package
The next step is to create the security enforcement package. The security enforcement
package will be executed when a user attempts to access the table that the security
enforcement package will be assigned to in the next step. To enforce the row-level
security, the security enforcement package adds a dynamic predicate to the SQL state-
ment that is being executed. The dynamic predicate becomes an additional restriction
to be appended to the SQL statement to be executed (basically, extending the WHERE
clause to include restrictions for the implementation of row security).
ENFORCING ROW-LEVEL SECURITY
Beyond Simple
Database Managment
PART
III
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 21 • ORACLE8i DATABASE SECURITY
962
You can actually take advantage of FGAC by just writing this policy package and
taking the next step, which is to register the package with the database. You don’t
need to use contexts to use FGAC.
In this example, you will append a predicate that basically says something to this
effect:
WHERE users_security_level>=tbl_secured_information.min_security_id
Thus, if the user’s security level is greater than the minimum required security level in
the TBL_SECURED_INFORMATION table, the user will be able to perform a given
operation on that table (such as UPDATE or SELECT). The security enforcement pack-
age (called PKG_TBL_SECURED_INFO_01 in this example) will construct this predi-
cate and return it as a VARCHAR2 datatype to the database, where it will be applied to
the SQL statement. Listing 21.9 provides an example of the creation of the security
enforcement package.
NOTE The additional predicate does not appear in data dictionary views of the SQL
statement, such as V$SQL.
Listing 21.9: Creating the Security Enforcement Package
CONNECT spy_owner/spy_owner
CREATE OR REPLACE PACKAGE pkg_spy_auth
AUTHID DEFINER AS
FUNCTION fu_spy_check(p_schema VARCHAR2, p_name VARCHAR2)
RETURN VARCHAR2;
END;
/
CREATE OR REPLACE PACKAGE body pkg_spy_auth
AS
FUNCTION fu_spy_check(p_schema VARCHAR2, p_name VARCHAR2)
RETURN VARCHAR2 AS
V_predicate VARCHAR2(2000);
V_clearance NUMBER;
BEGIN
V_clearance:=sys_context(’cont_spy_owner_01’,’v_spy_clearance’);
IF v_clearance IS NOT NULL
THEN
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
963
V_predicate:= ’ min_security_id <= ’||v_clearance;
ELSE
V_predicate:= ’ 1 = 2’;
END IF;
RETURN v_predicate;
END fu_spy_check;
END pkg_spy_auth;
/
This package retrieves from the cont_spy_owner_01 context the clearance level of
the person logged in to the database. It then checks to see if v_clearance is NULL,
which will be the case if the user signs in as someone who is not in the security clear-
ance table (TBL_USER_ID). If the user’s security clearance is set to NULL, the package
creates a predicate that makes the SQL statement return no rows. Since the clause 1 =
2 is always going to evaluate as FALSE, this guarantees that you prevent access to the
table to unauthorized users. Always include this clause to make sure your data is secured.
If the clearance is not NULL, the package creates a predicate that indicates that the
column MIN_SECURITY_ID should be less than or equal to the clearance level
assigned. Once this procedure is associated with the TBL_SECURED_INFORMATION
table, all queries will have this predicate attached to the end of them, thus enforcing
the security.
NOTE Some functions, such as DBMS_OUTPUT, will not execute in FGAC security
enforcement packages. The package will compile but no output will be forthcoming. Also,
autonomous transactions will cause a row-level security package to fail when executed.
This is likely seen as a circumvention of security by Oracle. The UTL_FILE package, strangely
enough, appears to work fine.
Registering the Security Enforcement Package
Now that you have written the security enforcement package, the final step is to
enforce the rules represented by this package and relate that package to a table. The
security enforcement package is related to the table through the use of the DBMS_RLS
package.
NOTE Oracle does not allow any security policies to apply to the SYS schema.
ENFORCING ROW-LEVEL SECURITY
Beyond Simple
Database Managment
PART
III
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 21 • ORACLE8i DATABASE SECURITY
964
The DBMS_RLS package is used to register your security enforcement package with
the table that you wish that package to administer, as well as to manage the security
enforcement packages. This package includes the DBMS_RLS.ADD_POLICY, DBMS_
RLS.DROP_POLICY, DBMS_RLS.ENABLE_POLICY, and DBMS_RLS.REFRESH_POLICY
procedures. In this example, you use the DBMS_RLS.ADD_POLICY procedure to regis-
ter the security enforcement package. Let’s take a quick look at that procedure:
PROCEDURE dbms_rls.add_policy
Argument Name Type In/Out Default?
OBJECT_SCHEMA VARCHAR2 IN DEFAULT
OBJECT_NAME VARCHAR2 IN
POLICY_NAME VARCHAR2 IN
FUNCTION_SCHEM VARCHAR2 IN DEFAULT
POLICY_FUNCTION VARCHAR2 IN
STATEMENT_TYPES VARCHAR2 IN DEFAULT
UPDATE_CHECK BOOLEAN IN DEFAULT
ENABLE BOOLEAN IN DEFAULT
Listing 21.10 shows how to use this procedure to register the security enforcement
package created with the database so it will execute on any DML statement that is
executed on the table TBL_SECURED_INFORMATION.
Listing 21.10: Adding the Policy with the DBMS_RLS.ADD_POLICY
Procedure
CONNECT SYS/yourpassword
BEGIN
Dbms_rls.add_policy(’SPY_OWNER’,’TBL_SECURED_INFORMATION’,
’SPY_OWNER’,’SPY_OWNER’, ’PKG_SPY_AUTH.FU_SPY_CHECK’,
’SELECT, INSERT, UPDATE, DELETE’,
TRUE, TRUE);
END;
/
As you can see, the DBMS_RLS.ADD_POLICY procedure takes several parameters.
Table 21.5 describes each parameter.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
965
TABLE 21.5: PARAMETERS FOR THE DBMS_RLS.ADD_POLICY PROCEDURE
Argument Default Value Description
Object_schema NULL The schema that contains the table or view that you
wish to register the policy for. If NULL, the current
user schema will be used.
Object_name None The name of the table or view that the policy is
being added to.
Policy_name None The name of the policy being assigned to the table
or view. This name must be unique for each object.
Function_schema NULL The name of the schema that owns the policy func-
tion that is to be used. If NULL, the current user that
you are logged in as will be used.
Policy_function None The name of the function/package that is used to
create the dynamic predicate (this is the security
enforcement package).
Statement_types All The statement types that the policy should apply to
(SELECT, INSERT, UPDATE, DELETE).
Update_check FALSE Causes the value to be checked again after an
UPDATE or INSERT statement completes.
Enable TRUE Enables the policy. The policy can be selectively
enabled or disabled with the DBMS_RLS.ENABLE
procedure.
NOTE When you begin planning your security with FGAC, you may end up crafting mul-
tiple policies for the same table. Oracle supports this type of approach, allowing you to
register multiple policies for the same table.
The other procedures in the DBMS_RLS package allow you to manage your poli-
cies. You can drop policies with the DROP_POLICY procedure, enable or disable poli-
cies with the ENABLE_POLICY procedure, and use the REFRESH_POLICY procedure to
cause all SQL statements associated with the policy to be re-parsed.
Testing the Security Enforcement Package
So, you’ve written code, set up logon triggers, created the security enforcement pack-
age, and added it as a security policy. You’re ready to go! Listing 21.11 provides the
ENFORCING ROW-LEVEL SECURITY
Beyond Simple
Database Managment
PART
III
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 21 • ORACLE8i DATABASE SECURITY
966
test. In this test, you log on to the database as each user and try to SELECT from the
table. Let’s see what happens.
Listing 21.11: Looking for a Security Breach
SQL> CONNECT spy_owner/spy_owner
Connected.
SQL> SELECT * FROM tbl_secured_information;
MIN_SECURITY_ID SECRET_INFORMATION
0 This is boring public information
10 Men are NOT from Mars!!
20 But the Aliens are from Mars!!
100 And they are here to take over the world.
SQL> CONNECT public_access/public_access
Connected.
SQL> /
no rows selected
SQL> CONNECT secret_spy/secret_spy
Connected.
SQL> /
MIN_SECURITY_ID SECRET_INFORMATION
0 This is boring public information
10 Men are NOT from Mars!!
SQL> CONNECT top_secret_spy/top_secret_spy
Connected.
SQL> /
MIN_SECURITY_ID SECRET_INFORMATION
0 This is boring public information
10 Men are NOT from Mars!!
20 But the Aliens are from Mars!!
SQL> CONNECT license_to_kill/license_to_kill
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
967
Connected.
SQL> /
MIN_SECURITY_ID SECRET_INFORMATION
0 This is boring public information
10 Men are NOT from Mars!!
20 But the Aliens are from Mars!!
100 And they are here to take over the world.
The Good, the Bad, and the Ugly about FGAC
As is typical of any new feature, there are some good things and some bad things
about using FGAC. The fact that FGAC works in the background, so that it is invisible
to the user, is one of the advantages of using FGAC. And, of course, there is the bene-
fit of making your database more secure.
The main negative aspect to FGAC is the complexity involved in implementing the
feature. However, once you have done it a couple of times, it becomes easier.
Another issue with FGAC is the fact that it has the potential to negatively impact
performance. Since the predicate to be added changes the SQL statement, you can
end up with an execution plan that is different from what you expected. Since you
have almost no way of knowing what predicate is being attached to the SQL state-
ment, it makes tuning that SQL statement much more difficult. The complete SQL
statement, with the predicate, doesn’t show up in the V$SQL view, and the predicate
doesn’t appear if you enable Autotrace. If you look in a trace file, you will not see a
predicate associated with your session.
Predicates can impact performance. Depending on the predicate to be added, you
could end up with more table joins than you expected, quickly turning a simple two
table join into a three- or four-table join (or more). As a developer, DBA, or database
architect, you need to consider the impacts of predicates and make sure that indexes
are created to assist the database in properly handling the addition of the predicates.
There is one way to determine what predicate is being added when you are run-
ning SQL statements: Add event 10730. Setting this event will provide you with a
trace file that contains the complete SQL statement you issued. This SQL statement
will also include the dynamic FGAC predicate attached. If you are using Oracle ver-
sion 8.1.5, your output will look somewhat different in that only the predicate will
appear. In Oracle version 8.1.6 and later, you will find that the entire SQL statement
appears, as shown here:
ALTER SESSION SET EVENTS= ‘10730 trace name context forever, level 10’;
ENFORCING ROW-LEVEL SECURITY
Beyond Simple
Database Managment
PART
III
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[...]... (BADFILE and DISCARDFILE), and the log file You’ll read about the various methods of loading data, and how to execute SQL*Loader from the command line or using a script NOTE The case studies in the Oracle documentation are good examples that will help you understand how to use SQL*Loader Introduction to SQL*Loader SQL*Loader will bring data in from a source external to Oracle and place that data into Oracle... can load data into the Oracle table faster, the direct path method has more restrictions Conventional path is what is used most often For more information about all three load methods, consult Oracle’s documentation on SQL*Loader Conventional Path Load Conventional path load is the default load type and will be used if you do not specify a load method You can use any of the record formats with this method... VARRAY • When table constraints are present Direct Path Load Restrictions on Direct Path Load The direct path load has several restrictions, including the following (For a complete list, consult the Oracle documentation.) • SQL strings are not allowed in the control file • The table into which you are loading data cannot contain LOB or VARRAY column types Please purchase PDF Split-Merge on www.verypdf.com... \control=1461c1.ctl log=servtype.log data=servtype.csv \bad=servtype.bad discard=servtyp.dis parallel=true \errors=10000 rows=1000 bindsize=100000000 Oracle has supplied a collection of case studies in the SQL*Loader documentation that may be of use to you in constructing your control files OPTIONS Clause The OPTIONS section contains the SQLLOAD command-line options You can specify these options within the control... REPLACE, or TRUNCATE) INTO TABLE is possibly the most complex clause of SQL*Loader’s control file NOTE For an in-depth breakdown of this control file section, you can go to Chapters 3 through 6 of the Oracle documentation on SQL*Loader If you specify INTO TABLE with one of the options INSERT, APPEND, REPLACE, or TRUNCATE, as described earlier, that option will take precedence over the INSERT, APPEND, REPLACE,... errors allowed and actual errors encountered • Makeup of the control file • When the load started and ended For more thorough coverage of the elements of SQL*Loader’s log files, consult the SQL*Loader documentation Listing 22.10: Example of SQL*Loader Log File Control File: Datafile: Bad File: /pac146/ctl/1463c.ctl /pac146/data/m1prj_midmo.txt /pac146/data/m1prj_midmo.bad Discard File: /pac146/data/m1prj_midmo.dis . from the command line or using a
script.
NOTE The case studies in the Oracle documentation are good examples that will help
you understand how to use SQL*Loader.
Introduction. often.
For more information about all three load methods, consult Oracle’s documenta-
tion on SQL*Loader.
Conventional Path Load
Conventional path load
Ngày đăng: 26/01/2014, 19:20
Xem thêm: Tài liệu ORACLE8i- P25 doc, Tài liệu ORACLE8i- P25 doc, Migrating an Existing 7.1+ Database to Oracle8i