Database Reference
In-Depth Information
By The WAy
You may be wondering what good it does to say that the system admin-
istrator cannot process the data when that person has the ability to grant
processing rights. He or she can just grant the right to change data to himself or herself.
Although this is true, the granting of those rights will leave an audit trail in the database
log. Clearly, this limitation is not foolproof, but it is better than just allowing the system
administrator (or DBA) full access to all rights in the database.
The permissions in this table are not given to particular people, but rather are given to
groups of people. Sometimes these groups are termed
roles
because they describe people act-
ing in a particular capacity. The term
user groups
is also used. Assigning permission to roles
(or user groups) is typical, but not required. It would be possible to say, for example, that the
user identified as “Benjamin Franklin” has certain processing rights. Note, too, that when roles
are used, it is necessary to have a way to allocate users to roles. When “Mary Smith” signs on
to the computer, there must be some way to determine which role or roles she has. We will
discuss this further in the next section.
In this discussion, we have used the phrase
processing rights and responsibilities
. As
this phrase implies, responsibilities go with processing rights. If, for example, the manager
modifies transaction data, the manager has the responsibility to ensure that these modifica-
tions do not adversely impact the gallery's operation, accounting, and so forth.
Processing responsibilities cannot be enforced by the DBMS or by the database applica-
tions. Instead, they are encoded in manual procedures and explained to users during systems
training. These are topics for a systems development text, and we will not consider them
further here—except to reiterate that
responsibilities
go with
rights.
Such responsibilities must
be documented and enforced.
According to Figure 9-1, the DBA has the task of managing processing rights and respon-
sibilities. As this implies, these rights and responsibilities will change over time. As the data-
base is used and as changes are made to the applications and to the structure of the DBMS, the
need for new or different rights and responsibilities will arise. The DBA is a focal point for the
discussion of such changes and for their implementation.
Once processing rights have been defined, they can be implemented at many levels: operat-
ing system, network, Web server, DBMS, and application. In the next two sections, we will con-
sider DBMS and application implementation. The other levels are beyond the scope of this text.
DBMS Security
The terminology, features, and functions of DBMS security depend on the DBMS product in
use. Basically, all such products provide facilities that limit certain actions on certain objects
to certain users. A general model of DBMS security is shown in Figure 9-15.
Eleanore Wu
James Johnson
Richard Ent
Figure 9-15
a Model of DBMS Security
Eleanore Wu can execute MonthEnd Stored Procedure.
James Johnson can alter all tables.
USER
PERMISSION
OBJECT
ROLE
Accounting can update CUSTOMER table.
Accounting
Tellers
Shop Managers
Unknown Public
Search WWH ::
Custom Search