没有合适的资源?快使用搜索试试~ 我知道了~
oracle dba宝典12
3星 · 超过75%的资源 需积分: 3 25 下载量 173 浏览量
2009-10-27
12:42:26
上传
评论 1
收藏 120KB PDF 举报
温馨提示
试读
24页
oracle dba宝典oracle dba宝典oracle dba宝典oracle dba宝典oracle dba宝典oracle dba宝典oracle dba宝典oracle dba宝典oracle dba宝典oracle dba宝典oracle dba宝典oracle dba宝典oracle dba宝典oracle dba宝典oracle dba宝典
资源推荐
资源详情
资源评论
Using Fine-
Grained Access
Control
A
n exciting new Oracle8i feature is the ability to implement
row-level security within the database. Oracle refers to
this as fine-grained access control. It addresses a problem that
has plagued application developers and security administrators
ever since client/server computing came into vogue. The
problem is that an impedance mismatch has existed between
the typical relational database’s implementation of security
at the object level, and the application developer’s need for
security to be implemented at the row level. For a long time
now, we have been able to define access rights to objects
such as tables or views at the database level, but row-level
security has almost always been forced down into the
application. Oracle8i changes all this by implementing features
that support fine-grained access control at the |database level.
Using Application Security
Application security is loosely defined as the enforcement of
limits on what a particular user can do using a given application.
Take a payroll application, for example. Any payroll application
is capable of adding new employees to the payroll, changing pay
rates, and so forth. Even though all these features are available,
you certainly don’t want all users to avail themselves of them.
Instead, you have a limited number of users who are allowed to
see and change sensitive data such as an employee’s pay rate.
You might have a larger pool of users with “look only” access.
You may have further restrictions; for instance, a manager
is allowed to see only his or her own employees. All of these
restrictions are typically enforced through some type of
row-level security.
12
12
CHAPTER
✦ ✦ ✦ ✦
In This Chapter
Using application
security
Understanding
application security
contexts
Writing security
policies
Using pre-8i
alternatives
✦ ✦ ✦ ✦
4623-6 ch12.f.qc 1/28/00 12:29 PM Page 327
328
Part III ✦ Nuts and Bolts
Implementing security in the application
Historically, implementing detailed security policies at the database level has
been difficult. Sometimes you can do it using a combination of views and stored
procedures, but the amount of human overhead needed to manage all that is
high. Third-party development tools, such as Visual Basic and Powerbuilder,
are designed around using tables and views, making it cumbersome to funnel all
access through stored procedures. Because of these difficulties, row-level security
is often implemented at the application level, as illustrated in Figure 12-1.
Figure 12-1: Row-level security is often implemented within the application.
When row-level security is implemented as shown in Figure 12-1, you typically run
into these problems:
✦ The programmers don’t always get it right.
✦ Implementation is inconsistent from one application to another.
✦ The application maintenance burden is greatly increased.
✦ There is no security when ad-hoc query tools are used.
Oracle8i now offers an alternative approach. Read on to learn about it.
Using application contexts and policies
With the release of Oracle8i, you now have two new database features that enable
you to define row-level security within the database consistently, and in a way that
is transparent to users and applications accessing the database: security policies
and application contexts. Together, you can use these two features to move row-
level security from the application into the database, as shown in figure 12-2.
You can use application contexts and security policies separately. Application
contexts have uses other than for security. Security policies can be implemented
without using an application context. However, any reasonably robust security
scheme is likely to leverage both features.
Application Database
emp
dept
Security
Logic
Queries
Results
4623-6 ch12.f.qc 1/28/00 12:29 PM Page 328
329
Chapter 12 ✦ Using Fine-Grained Access Control
Figure 12-2: Oracle8i allows you to move application security into the database.
Using Security Policies
A security policy is a set of rules, attached to an object such as a table or a view, that
defines who is allowed to see data from the object, what rows they are allowed to see,
and whether those rows can be updated or deleted. You implement security policies
by writing PL/SQL code to dynamically modify the
WHERE clauses of queries against
the object being secured.
Figure 12-3 illustrates how a security policy actually works. A query has been
issued against the
EMP table in an attempt to select all rows from that table. When
the query is issued, Oracle automatically invokes the security policy for the
EMP
table. The security policy is nothing more than a PL/SQL package that looks up
some information about the user, and uses that information to modify the query’s
WHERE clause. All this is done transparently. The user never sees the modified
query. In this case, the end result is that a manager will be allowed to see only
his or her own employees.
Figure 12-3: Security policies dynamically rewrite the WHERE clause of a query.
For performance reasons, if nothing else, you will want to use application contexts
in a row-level security scheme. If a security policy needs to retrieve information
from the database and needs to retrieve that information each time it is invoked,
performance will suffer.
Database
emp
dept
Security
Logic
Select *
From emp
Select *
From emp
WHERE mgr_id = X
Application Database
emp
dept
Security
Logic
Queries
Results
4623-6 ch12.f.qc 1/28/00 12:29 PM Page 329
330
Part III ✦ Nuts and Bolts
Using Application Contexts
An application context is a scratchpad area in memory that you can use to store bits of
information that security policies need. For example, when a user logs on, you might
store his or her username, ID number, department number, and other information in
an application context. That information can then be referenced by the code that
enforces the security policies on objects that the user accesses. Figure 12-4 shows
the complete relationship between security policies, application contexts, and the
object being secured.
Figure 12-4: Security policies and application contexts work together to
secure an object.
Application contexts are restricted to prevent users from arbitrarily updating
their context data. When you create an application context, you also need to
create a PL/SQL package that you can use to define attributes in that context.
The command to create the context links the context to the package. After
a context is created, Oracle ensures that only the specified package can be
used to define attributes (save values) in that context.
Examining a Seapark Example
The rest of this chapter implements a row-level security model for the Seapark
database. The basic rule of that model is this:
The records of animals and tanks may be modified only by the caretaker
responsible for the animal or tank in question.
The examples throughout this chapter illustrate how to build the context and the
policies to support this model. This won’t be a comprehensive implementation. The
example is limited to just the
AQUATIC_ANIMAL and TANK tables, but that should be
enough to provide you with a good understanding of how all this works.
Database
Table
Security
Policy
Modified
Queries
Application
Context
Context
Attributes
Context
Attributes
Application
SQL
Queries
One Specific
PL/SQL Package
4623-6 ch12.f.qc 1/28/00 12:29 PM Page 330
331
Chapter 12 ✦ Using Fine-Grained Access Control
Understanding Application Security Contexts
An application security context functions as a glorified scratchpad. It is an area in
memory where you can store information that you may need occasionally during
a session. You define the information that you need to store in terms of attributes.
Each attribute in a context has a name and a value. Both the name and the value
are text strings that you supply when you create the attribute.
Creating and dropping a context
You manage contexts using the CREATE CONTEXT and DROP CONTEXT commands.
The
CREATE command creates; the DROP command deletes. There is no ALTER
CONTEXT
command.
Creating a Context
Before creating a context, you must think up a name. The name can be anything
you like, as long as it conforms to Oracle’s naming rules for objects. Try to give
the context a name that reflects the application that it is associated with. The
syntax for the
CREATE CONTEXT command looks like this:
CREATE [OR REPLACE] CONTEXT context_name
USING [schema.]package;
The package name that you supply when you create a context identifies the PL/SQL
package that is allowed to create and set attributes within the context. The package
doesn’t need to exist when you create the context. You can create it afterwards.
Creating a context doesn’t really create anything in the sense that creating a table
does. When you create a context, all that really happens is that you get a new entry
in the data dictionary. Contexts never use disk space, and they use memory only
when attributes are set.
You must have the CREATE ANY CONTEXT system privilege to create a context.
Because contexts aren’t created often, and because they are global to the entire
database, you may want to do all the context creating yourself, rather than grant
this role to a user.
Dropping a Context
You use the DROP CONTEXT command to remove a context. The syntax is simple,
and it looks like this:
DROP CONTEXT context_name;
When you drop a context, its entry is removed from the data dictionary, and you
can no longer define attributes for that context. However, users who currently have
attributes set for the context will retain those attributes until they disconnect.
Note
4623-6 ch12.f.qc 1/28/00 12:29 PM Page 331
剩余23页未读,继续阅读
资源评论
- huzibaba2014-05-22只是其中一章,没有看下去
bananaxzw
- 粉丝: 1
- 资源: 31
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- .archivetemp04 - 继承和多态 作业.doc
- 基于运动学车辆模型的开放式驾驶MPC横向控制算法Analyzed commaai Openpilot MPC lateral c
- STM32F103单片机源码STM32-74HC595串转并控制数码管显示
- python语言教程项目案例
- 斐波那契数列java代码 FibonacciProblem
- 服务器的概要介绍与分析
- logseq-linux包
- 蓝色简历首页的微信小程序模板源码
- 基于MPC的仿真轨迹跟踪模块MPC-based Simulink trajectory tracking module
- 递归地求解Fibonacci数列.pdf
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功