0% found this document useful (0 votes)
20 views19 pages

Ch05 Security Authorization

Uploaded by

Taola wibu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
20 views19 pages

Ch05 Security Authorization

Uploaded by

Taola wibu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 19

Security and Authorization

Chapter 5
Chapter outline
 Introduction to DB Security
 Security Levels
 Access Controls
 GRANT and REVOKE of Privileges
 GRANT/REVOKE on Views
 Role-Based Authorization
Introduction to DB Security

 Secrecy: Users should not be able to see


things they are not supposed to.
 E.g., A student can’t see other students’ grades.
 Integrity: Users should not be able to modify
things they are not supposed to.
 E.g., Only instructors can assign grades.
 Availability: Users should be able to see and
modify things they are allowed to.
Security Levels
 A user passes through 2 stages of security in
DBMS
 Authentication – validates that a user can connect
to a SQL Server instance (Login)
 Authorization – permissions validation; controls
the activities the user is allowed to perform in the
SQL Server database (User)
Northwind

LOGIN ID UserName
Pubs

John
Authentication - provides Permissions - provides
Access to SQL Server access to a database

SQL Server
Instance Expense

Databases
Access Controls

 A security policy specifies who is authorized


to do what.
 A security mechanism allows us to enforce a
chosen security policy.
 Two main mechanisms at the DBMS level:
 Discretionary access control
 Mandatory access control
Discretionary Access Control

 Based on the concept of access rights or


privileges for objects (tables and views), and
mechanisms for giving users privileges (and
revoking privileges).
 Creator of a table or a view automatically gets
all privileges on it.
 DMBS keeps track of who subsequently gains and
loses privileges, and ensures that only requests
from users who have the necessary privileges (at
the time the request is issued) are allowed.
GRANT Command
GRANT privileges ON object TO users [WITH GRANT OPTION]
 The following privileges can be specified:
 SELECT: Can read all columns (including those added later via
ALTER TABLE command).
 INSERT(col-name): Can insert tuples with non-null or non-
default values in this column.
 INSERT means same right with respect to all columns.
 DELETE: Can delete tuples.
 REFERENCES (col-name): Can define foreign keys (in other
tables) that refer to this column.
 If a user has a privilege with the GRANT OPTION, can
pass privilege on to other users (with or without
passing on the GRANT OPTION).
 Only owner can execute CREATE, ALTER, and DROP.
Revoking Privileges

REVOKE <list of privileges>


ON <relation or other object>
FROM <list of authorization ID’s>;
 Your grant of these privileges can no longer
be used by these users to justify their use of
the privilege.
 But they may still have the privilege because they
obtained it independently from elsewhere.

8
REVOKE Options

 We must append to the REVOKE statement


either:
1. CASCADE. Now, any grants made by a
revokee are also not in force, no matter how far
the privilege was passed.
2. RESTRICT. If the privilege has been passed to
others, the REVOKE fails as a warning that
something else must be done to “chase the
privilege down.”

9
GRANT and REVOKE of Privileges
Examples
 GRANT INSERT, SELECT ON Sailors TO Horatio
 Horatio can query Sailors or insert tuples into it.

 GRANT DELETE ON Sailors TO Yuppy WITH GRANT


OPTION
 Yuppy can delete tuples, and also authorize others to do so.

 GRANT UPDATE (rating) ON Sailors TO Dustin


 Dustin can update (only) the rating field of Sailors tuples.

 GRANT SELECT ON ActiveSailors TO Guppy, Yuppy


 This does NOT allow the ‘uppies to query Sailors directly!
Example: Privileges

 For the statement below: beers that do


not appear in
INSERT INTO Beers(name) Beers. We add
SELECT beer FROM Sells them to Beers
with a NULL
WHERE NOT EXISTS manufacturer.
(SELECT * FROM Beers
WHERE name = beer);
 We require privileges SELECT on Sells and
Beers, and INSERT on Beers or Beers.name.
11
Example: Grant Diagram
A: GRANT P B: GRANT P
TO B WITH TO C WITH
GRANT OPTION GRANT OPTION
AP** BP* CP*

A owns the
object on CP
which P is A: GRANT P
a privilege TO C

12
Example: Grant Diagram
Not only does B lose
P*, but C loses P*.
A executes
Delete BP* and CP*.
REVOKE P FROM B CASCADE;

AP** BP* CP* Even had


C passed P
to B, both
nodes are
still cut off.
CP
However, C still
has P without grant
option because of
the direct grant.

13
GRANT/REVOKE on Views

 If the creator of a view loses the SELECT


privilege on an underlying table, the view is
dropped!
 If the creator of a view loses a privilege held
with the grant option on an underlying table,
(s)he loses the privilege on the view as well;
so do users who were granted that privilege
on the view!
Views and Security
 Views can be used to present necessary
information (or a summary), while hiding
details in underlying relation(s).
 Creator of view has a privilege on the view if
(s)he has the privilege on all underlying tables.
 Together with GRANT/REVOKE commands,
views are a very powerful access control tool.
Authorization ID’s

 A user is referred to by authorization ID,


typically their login name.
 There is an authorization ID: PUBLIC.
 Granting a privilege to PUBLIC makes it available
to any authorization ID.

16
Role-Based Authorization
 In SQL-92, privileges are actually assigned to
authorization ids, which can denote a single
user or a group of users.
 In SQL:1999 (and in many current systems),
privileges are assigned to roles.
 Allow you to collect users into a single unit
against which you can apply permissions
 Permissions are applied automatically when the
users become members of the role
 Roles can then be granted to users and to other
roles.
 Reflects how real organizations work.
 Illustrates how standards often catch up with “de
facto” standards embodied in popular systems.
Summary

 Three main security objectives: secrecy, integrity,


availability.
 DB admin is responsible for overall security.
 Designs security policy, maintains an audit trail, or history of
users’ accesses to DB.
 Two main approaches to DBMS security: discretionary
and mandatory access control.
 Discretionary control based on notion of privileges.
 Mandatory control based on notion of security classes.
 Statistical DBs try to protect individual data by
supporting only aggregate queries, but often, individual
information can be inferred.
Assigments
 Grant and Revoke in SQL Server or Oracle.
 Roles: Server roles, Database roles, Application Roles
(Fixed roles và user defined roles)
 Roles in security
 Creating and management Roles in SQL-Server or Oracle
(with Management Studio or transaction (SQL-Server))

You might also like