Database Security
Antoine POTTIN
Management of users
Introduction to Grant and Revoke commands
Syntax and semantic of Grant and Revoke in :
. MySQL
. Postgres
. Oracle
. Microsoft SQL
Database Security
Example of Implementation (in Oracle)
Grant and Revoke
The Grant and Revoke commands allow system system administrators to create users.
Grant is implemented in MySQL Version 3.22.11 or later, for earlier versions, the Grant statment does nothing.
Management of users
Database Security
Grant and Revoke: Definition
Management of users
Database Security
Grant:
The GRANT statement is used to give permissions to a user or role. By using the GRANT statement, it is possible to assign permissions to both statements as well as objects. You can use the GRANT statement with the WITH GRANT OPTION clause to permit the user or role receiving the permission to further grant/revoke access to other accounts
Grant and Revoke: Definition
Management of users
Database Security
Revoke:
The REVOKE statement is used to remove a previously granted or denied permission from a user in the current database. You can use the REVOKE statement to remove both statements and objects permissions. You can specify the GRANT OPTION FOR clause with the REVOKE statement to remove the WITH GRANT OPTION permissions. Therefore, the user will have the objects permissions, but cannot grant the permissions to other users. Specify the CASCADE clause along with the WITH GRANT OPTION clause, if the permissions being revoked were originally granted using the WITH GRANT OPTION setting.
Users or Grant and Revoke rights are created at 4 levels
Global level
Database level
Column level
Table level
Rights LevelsManagement of users
Database Security
Grant and Revoke
Global level Global privileges apply to all databases on a given server.
Global level
server
Management of users
Database Security
Grant and Revoke
Rights Levels
Database level
server
Database level Database privileges apply to all tables in a given database.
database
database
Management of users
Database Security
Rights Levels
Grant and Revoke
Table level
server
database
database
table
table
table
Table level Table privileges apply to all columns in a given table.
Management of users
Database Security
Rights Levels
Grant and Revoke
Column level
server
database
database
table
table
table
column
column
columncolumn
Column level Column privileges apply to single columns in a given table.
Management of users
Database Security
Rights Levels
Grant and Revoke
Management of users
Database Security
Grant and Revoke Syntax & Sémantic
MySQL
GRANT priv_type [(column_list)] [, priv_type [(column_list)] ...] ON {tbl_name | * | *.* | db_name.*} TO user_name [IDENTIFIED BY 'password'] [, user_name [IDENTIFIED BY 'password'] ...] [WITH GRANT OPTION] REVOKE priv_type [(column_list)] [, priv_type [(column_list)] ...] ON {tbl_name | * | *.* | db_name.*} FROM user_name [, user_name ...]
Management of users
Database Security
Grant and Revoke Syntax & Sémantic
Postgres
REVOKE { { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES | TRIGGER } [,...] | ALL [ PRIVILEGES ] } ON [ TABLE ] tablename [, ...] FROM { username | GROUP groupname | PUBLIC } [, ...]
GRANT { { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES | TRIGGER } [,...] | ALL [ PRIVILEGES ] } ON [ TABLE ] tablename [, ...] TO { username | GROUP groupname | PUBLIC } [, ...]
Management of users
Database Security
Grant and Revoke Syntax & Sémantic
Oracle
REVOKE SELECTON employee FROM BOB;
GRANT SELECT, INSERT, UPDATE, DELETE ON DEPARTMENT TO username;
Management of users
Database Security
Grant and Revoke Syntax & Sémantic
Microsoft SQL
GRANT SELECT, ... ON tableTO username
REVOKE SELECT, ... ON table TO username
Management of users
Database Security
Grant and Revoke Example
of Implementation (Oracle)
For example, if you wanted to grant select, insert, update, and delete privileges on a table called suppliers to a user name smithj, you would execute the following statement:
grant select, insert, update, delete on suppliers to smithj;
You can also use the all keyword to indicate that you wish all permissions to be granted. For example:
grant all on suppliers to smithj;
If you wanted to grant select access on your table to all users, you could grant the privileges to the public keyword. For example:
grant select on suppliers to public;
Implementation of Grant:
Management of users
Database Security
Grant and Revoke Example
of Implementation (Oracle)
Implementation of Revoke:
Once having granted privileges, you may need to revoke some or all of these privileges. To do this, you can execute a revoke command. You can revoke any combination of select, insert, update, delete, references, alter, and index.
For example, if you wanted to revoke delete privileges on a table called suppliers from a user named anderson, you would execute the following statement:
revoke delete on suppliers from anderson;
If you wanted to revoke all privileges on a table, you could use the all keyword. For example:
revoke all on suppliers from anderson;
If you had granted privileges to public (all users) and you wanted to revoke these privileges, you could execute the following statement:
revoke all on suppliers from public;
Management of users
Database Security
Oracle Label Security
(OLS)
Available from the Oracle9i version
Presentation of OLS in a project: sales force administration
Project
Database Security
Sales force administrationOracle OLS
This demonstration is to prove the powerfull features of OLS. In the following diapos, I will illustrate how to implement the following business functional requirements for a new sales force administration application.
Let’s assume that a growing company based in France ;) has decided to formalize the sales force along geographic boundaries:
The sales force is responsible for managing customer contact in five french regions: northwest, northeast, southwest, southeast and Paris area.
Project
Database Security
Sales force administrationOracle OLS
-A Regional Sales Director will manage each Region.
-Each regional sales director reports to and is managed by the Executive sales director.
-Each region will be divided into 2 districts,
and each district will consist of a subset of french departments.
Project
Database Security
Sales force administrationOracle OLS
So far, it looks like a standard implementation for a sales force. We know that database objects are needed to store informations about the region and districts that makes up the sales force. That is the next set of requirements that makes OLS an attractive option:
-Each Regional Manager can view and maintain historical customer contact information only for those customers in the Region for which he/she is responsible.
-Only the Executive Sales Director can view and maintain customer contact information history in all Regions.
Project
Database Security
Sales force administrationOracle OLS
To demonstrate these requirements for the new sales administration system, it is necessary to:
-create a new schema (SALESADM), a new role (SALESADM_ROLE), and several new users.like in Listing 1.1
-To built sample tables for Sales Regions, Sales Districts, Sales Zones (i.e. the geographical areas covered) and Customer Contact information. Like in Listing 1.2
-To creat a few views (see Listing 1.3) that will be used to gather data from the existing Sales History (SH) schema that is included as part of the standard Oracle example database to demonstrate how OLS-secured information can be used to control access to other, non-secured schemas as well. See Listing 1.3
-Finally, to load these sample tables with appropriate data to illustrate application of OLS features (see Listing 1.4).
Project
Database Security
Sales force administration
Oracle OLS
Now that we have a realistic sample schema and sufficient data loaded to illustrate, let's turn our attention to applying OLS to these objects. OLS provides several packages that allow to create and maintain the necessary objects that enforce its security. Except where otherwise noted in the following examples,we will be running scripts from the OLS administrator login (LBACSYS)
A sample OLS implementation
Project
Database Security
Sales force administration
Oracle OLS
The first step is to establish an OLS security policy. This policy will encompass all of the OLS settings and assignments that will enforce the security. Via the SA_SYSDBA.CREATE_POLICY function, I will create a new policy named SADM (Sales Administration), and I will specify the name of the column (SADM_LBL) that will be added to each table that will be needed to secure. For the sake of security, It will also be the security policy to hide the SADM_LBL from the prying eyes of developers or more advanced users who might be writing queries against database tables.
See Listing 2.1 for the script used to create the security policy.
A sample OLS implementation
Creating a new security policity
Project
Database Security
Sales force administration
Oracle OLS
Now that is created the security policy, the next step is to create the necessary components for enforcement.
First, create a set of security levels that specify the sensitivity of the data being protected. OLS allows to specify:
•Level Number. A numeric value used to uniquely identify each security level. It is a good idea to make the higher level numbers correspond to the increasing security required.
•Short Name. Essentially an abbreviation for the level; it will be used when creating data and user labels, so it's a good idea to keep it short – one or two characters.
•Long Name. A more detailed description of the security level.
A sample OLS implementation
Creating Security Components:
Levels, Compartments, and Groups
Project
Database Security
Sales force administration
Oracle OLS
Via the OLS package procedure SA_COMPONENTS.CREATE_LABEL, here are the security levels seted up for this policy:
A sample OLS implementation
Creating Security Components:
Levels, Compartments, and Groups
Table 1. Security Levels
Level ID
Short Name
Long Name
1000 UN Unsecured
3000 CW CompanyWide
5000 CC CompanyConfidential
7000 TS Trade SecretSee Listing 2.2 for the script used to create the security levels.
Project
Database Security
Sales force administration
Oracle OLS
Next, to create a set of security compartments. Compartments are used to restrict the areas to which data is restricted. OLS allows to specify:
-Compartment Number. A numeric value used to uniquely identify each security compartment.
-Short Name. An abbreviation for the compartment that will be used when creating data and user labels, so it is a good idea to keep it short – one or two characters.
Long Name. A more detailed description of the security compartment
A sample OLS implementation
Creating Security Components:
Levels, Compartments, and Groups
Project
Database Security
Sales force administration
Oracle OLS
Here are the security compartments seted up for this policy using the OLS package procedure SA_COMPONENTS.CREATE_COMPARTMENT:
A sample OLS implementation
Creating Security Components:
Levels, Compartments, and Groups
Table 2. Security Compartments
Compartment ID
Short Name
Long Name
100 AC Accounting
200 SA Sales Administration
300 HR Human Resources
400 OP Operations
500 OE Order EntrySee Listing 2.3 for the script used to create the security compartments
Project
Database Security
Sales force administration
Oracle OLS
Finally, create a set of security groups. Groups are used to limit data access to the owners of the data; they can also store hierarchical relationships. OLS allows to specify:
•Group Number. A numeric value used to uniquely identify each security group. It’s helpful to create group numbers that represent their hierarchical relationships (see below).
•Short Name. An abbreviation for the group that will be used when creating data and user labels. Again, best to keep this short as possible.
•Long Name. A more detailed description of the security group.
•Parent. Identifies which one group is the parent of the current group entry; used in building a hierarchical relationship.
A sample OLS implementation
Creating Security Components:
Levels, Compartments, and Groups
Project
Database Security
Sales force administration
Oracle OLS
Via the OLS package procedure SA_COMPONENTS.CREATE_GROUP, set up the following security groups for this policy:
A sample OLS implementation
Creating Security Components:
Levels, Compartments, and Groups
Table 3. Security Groups
Group ID
Short Name
Long Name Parent
0 T Top of Sales Force Hierarchy (none)
10 NE Northeastern Sales Region T
20 SE Southeastern Sales Region T
30 CN Central Sales Region T
40 SW Southwestern Sales Region T
50 NW Northwestern Sales Region T
See Listing 2.4 for the script used to create the security groups.
Project
Database Security
Sales force administration
Oracle OLS
Now that we have all the security policy's components in place, ready to build the actual labels that will be used to enforce the policy. Recall that these need to be applied to both users and to the data to be protected. OLS allows to specify:
-Label ID. A numeric value used to uniquely identify each policy label. Oracle recommends that it is best to use the Label ID value to arrange the labels into common-sense groupings, since the Label ID is used extensively during retrieval of and decision making about secured data.
-Label Tag. The tag represents the intersection of security level, security compartment, and security groupings, and takes the format of level:[compartments]:[groups].
A sample OLS implementation
Creating Policy Labels
Project
Database Security
Sales force administration
Oracle OLS
We set up the following policy labels for this policy using the OLS package procedure SA_LABEL_ADMIN.CREATE_LABEL. Note the labels in the 30100-30199 range; they will be used extensively in my next steps for applying security to the sales force administration application's users tables:
A sample OLS implementation
Creating Policy Labels
Table 4. Policy Labels
Label ID Label Tag
10000 UN
10100 UN:AC
10200 UN:SA
10300 UN:HR
10400 UN:OP
10500 UN:OE
30000 CW
30100 CW:SA:T
30110 CW:SA:NE
30120 CW:SA:SE
30130 CW:SA:CN
30140 CW:SA:SW
30150 CW:SA:NW
50000 CC
70000 TSSee Listing 2.5 for the script used to create the security groups.
Project
Database Security
Sales force administration
Oracle OLS
Once policy labels have been established, it's time to apply them to the users whose data access must be restricted. Previously is created six users: SLSMGR (for use by the Executive Sales Director) and RGNMGR1 through RGNMGR5 (for use by the five regional sales directors). We have applied the appropriate SADM policy labels to these users via the OLS package procedure SA_USER_ADMIN.SET_USER_LABELS.
A sample OLS implementation
Applying Policy Labels to Users
See Listing 2.7 for the script used to apply the policy to database object tables.
Project
Database Security
Sales force administration
Oracle OLS
Just before we start labeling data in the tables for which the policy has been approved, it’s made sure that the owner of those tables – SALESADM – has the appropriate permission to maintain security policies for the data within its schema. It’s done this via the OLS package procedure SA_USER_ADMIN.SET_USER_PRIVS.
A sample OLS implementation
Authorizing Schema Owner Rights
See Listing 2.8 for the script used to authorize the schema owner to maintain this information.
Project
Database Security
Sales force administration
Oracle OLS
Now is ready to apply row-level security to individual rows in the tables that is identified to OLS for such control. Start at the highest level in the sales force hierarchy by securing specific rows in the SALES_REGION table based on the regions represented by each row. Note that is used the CHAR_TO_LABEL function to translate the text-based label into its corresponding label identifier.
A sample OLS implementation
Applying Security Labeling to Specific Rows
See Listing 2.9 for the script used to update selected tables with the appropriate security policy labels.
Top Related