This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Grant based security planning provides access for a particular class of users and also ensures that each and every role is carefully designed. Roles can be created from active roles and to avoid overlapping a hierarchy of roles is created. It requires user knowledge and their responsibilities and also uses a structured process for creation of roles.
Grant security in Oracle has the following forms:
System privilege grants
System and Object privileges
According to Burleson (2003), "A privilege is permission to access a named object in a prescribed manner; for example, permission to query a table". These are granted to users by the judgement of other users (administrators), and are granted to allow a specific user to connect to the database and create a session i.e. create tables; execute someone's stored procedure or select rows from someone's table.
System privileges let uses carry out a specific system wide action or a specific action on a specific type of schema object, such as: privileges to delete rows of any table or create a table in the database are system privileges. The privileges which are powerful are only available to application developers and administrators.
Schema Object privileges
Access to data is commonly controlled by the access level to particular tables or to the database itself. Schema object privileges permit users to carry out a specific action on a particular schema object, such as: the privilege to delete rows of a particular table in an object privilege.
It is possible to specify privileges at the column level and to restrict user's UPDATE and INSERT privileges for a table to individual columns of the table. Similarly, it is possible to specify privileges at row level and to restrict a user's INSERT, DELETE, UPDATE and SELECT privileges for a table to particular rows of the table.
Generally, the object owner can only grant the object privileges, however, an owner can state that a specific user has the rights for granting a privilege to other users.
Managing System and Object privileges
The initial stage of authorization for a user to access a database should be to supply a valid username and password. The additional techniques to further manage the object privileges and the system are as follows:
Using roles to manage privileges
To provide authorisation, a role mechanism can be used i.e. a single user or a group of users can be allocated a role or a group of roles. Administrators are able to manage access privileges more effortlessly by defining the types of roles. These roles are as follows:
Database roles: Privileges allow users to amend and access data within the database. The database roles are named groups of privileges describing to a particular job function which are granted to users or other roles. Privileges are usually granted to roles rather than particular users as roles permit for easier and better management of privileges. Better granularity of access controls and adhere to the principle of least privilege can be achieved by applying various levels of privileges and roles, as shown in Figure 1:
Figure 1: Level of roles and privileges
Global roles: One component of enterprise user security is global roles. This only applies to one database but it is possible to grant it to an enterprise role which is defined in the enterprise directory.
Secure application role: One major security problem for enterprises is limiting how users can access data, to prevent them from accessing data directly and bypassing application logic. This can challenge can be addressed by a secure application role i.e. a role implemented by a package.
Enterprise roles: This is a directory structure which includes global roles on multiple databases which can be granted to enterprise users.
Using views to manage privileges
Users can be given the access to view the table instead of granting privileges on a particular table. Views can add the following two levels of security:
Limiting access only to certain columns of the base table.
Providing value-based security for the data in a table. Hence, in the definition of a view, a WHERE clause will only display the selected rows of the base table.
In order to use a view, only suitable privileges for the view are required and the user may not be provided with the privileges on base objects underlying the view.
Example of view:
Complex and Dynamic Views
Among the past approaches to row level security are complex views and dynamic views. When application designers build their own user security tables and join the application tables with new security tables which are based on the name of the application user, result in a complex view. Many complex views definitions are required in this approach as security requirements change. On the other hand, Dynamic view creation uses dynamic DDL execution utilities to describe new view definitions which are based on the individuality of the application user. However, this approach is time consuming and costly.
Limitations to role privileges
There are certain limitations to role privileges. These are as follows:
These are defined at the object level for an entire table and not for specific rows in table.
Sufficient for many applications
Some sensitive areas may require more controls, for example: Health, financial and personal information.
Limitations to Grant model
The grant model also has few limitations, as follows:
These can be difficult to coordinate on a large scale level.
It can be exceptionally complex
There are new methods available to overcome this:
New methods have been developed to overcome this, such as:
Grant execute model (Definer and invoker rights)
VPD (Predominantly used in web based applications)
Row Level Security
Row level access is a greater granular form of data access. Access to specific rows for any table with data can rely on considerations such as: employee's department, their title or job responsibility or any other significant factors. Complex and dynamic views have been generally used to implement row level security but there are two more effective approaches to this:
Virtual Private Database (VPD), where one can create their own implementation of row level security;
Label-based access control, where one can customize a ready-made VPD policy to achieve this.
Virtual Private Database
Virtual Private Database (VPD) is defined as the capability to execute query modification based on a security policy described in a package and related with a view, table or synonym. VPD provides fine-grained access control which is data-driven, row-based and context-dependent. It builds three-tier systems which expose mission-critical resources to partners and customers and it also uses PL/SQL functions to define the security logic.
Benefits of VPD:
The benefits to using VPD are as follows:
More than one policy on each object
Stack highly specific policies on other base policies
Good for Web applications
Row-level security easily differentiates between users
No back doors
Users can't avoid security policies embedded in applications
The security policy is attached to the data
ITIL process for access management:
The above mentioned strategies follow the ITIL access management process within the ITIL framework. Access management is a process which grants the rights to authorised users to utilise the services and at the same time prevents unauthorised access. This process is also called Identify and Access Management (IAM) which can deal with the following:
Services or service groups
Access management is the execution of information security management in such a way that it guarantees organisations the confidentiality, integrity and availability of the services and corporate data. (Glenfis.A, 2009)
Figure 2, gives an overview of the access management process:
Figure2: Access management overview.
This report has discussed the different ways available in Oracle to control data access rules within E & O Rilleys. The limitations are clearly outlined which can be beneficial when selecting any one of these options. Each access method is successful but combining methods will not be effective as it can have a negative effect on the system. For example: Using a role-based security and VPD system can prove difficult to determine access as to which user has access to which table.
These access rules and strategies are within the ITIL framework of access management as explained in the report as well. The staff can use any of these strategies to employ system control within the company with maintaining high security level.