0% found this document useful (0 votes)
113 views9 pages

Ijert Ijert: Database Security & Access Control Models: A Brief Overview

This document discusses database security and access control models. It begins by outlining some common threats to database security, such as privilege abuse, platform vulnerabilities, and denial of service attacks. It then discusses the importance of defining proper security policies to address these threats. These policies include access control, inference control, user authentication, and audit policies. The document goes on to introduce three main types of access control models - discretionary access control (DAC), mandatory access control (MAC), and role-based access control (RBAC). It notes that access control models provide formal descriptions of security policies and allow testing policies for completeness and consistency.

Uploaded by

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

Ijert Ijert: Database Security & Access Control Models: A Brief Overview

This document discusses database security and access control models. It begins by outlining some common threats to database security, such as privilege abuse, platform vulnerabilities, and denial of service attacks. It then discusses the importance of defining proper security policies to address these threats. These policies include access control, inference control, user authentication, and audit policies. The document goes on to introduce three main types of access control models - discretionary access control (DAC), mandatory access control (MAC), and role-based access control (RBAC). It notes that access control models provide formal descriptions of security policies and allow testing policies for completeness and consistency.

Uploaded by

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

International Journal of Engineering Research & Technology (IJERT)

ISSN: 2278-0181
Vol. 2 Issue 5, May - 2013

Database Security & Access Control Models: A Brief Overview


Kriti, Indu Kashyap
CSE Dept.
Manav Rachna International University, Faridabad, India

Abstract
1.1 Threats to Database Security
Database security is a growing concern evidenced A threat can be identified with a hostile agent
by increase in number of reported incidents of loss who either accidently or intentionally gains an
of or unauthorized exposure of sensitive data. unauthorized access to the protected database
Security models are the basic theoretical tool to resource [3] [4].
start with when developing
UNIT
a security system. These In organizations there are top ten type of threats
UNIT 3
models enforce security policies which are are recognized with can’t only increase the risk of
governing rules adopted by any organization. database exposure but also cause disastrous
Access control models are security models whose consequences on the entire organization. Some of
purpose is to limit the activities of legitimate users. these threats are described below [19]:
The main types of access control include
discretionary, mandatory and role based. All the Threat 1 - Excessive Privilege Abuse
three techniques have their drawbacks and When users (or applications) are granted
benefits. The selection of a proper access control database access privileges that exceed the
model depends on the requirement and the type of requirements of their job function, these privileges
attacks to which the system is vulnerable. The aim may be abused for malicious purpose.
of this paper is to give brief information on
database security threats and discusses the three Threat 2 - Legitimate Privilege Abuse
RT
models of access control DAC, MAC & RBAC. Users may also abuse legitimate database
privileges for unauthorized purposes.

Threat 3 - Platform Vulnerabilities


IJE

1. Introduction Vulnerabilities in underlying operating systems


Information is a critical resource in today’s may lead to unauthorized access, data corruption,
enterprise, whether it is industrial, commercial, or denial of service.
educational etc. As the organizations increase their
adoption of database systems as the key data Threat 4 - SQL Injection
management technology for day-to-day operations In a SQL injection attack, attacker typically
and decision making, the security of data becomes inserts unauthorized database statements into a
crucial [14]. The Defence Information System vulnerable SQL data channel.
Agency of US Department of defence states that
database security should provide controlled, Threat 5 - Denial of Service
protected access to the contents of database as well Denial of Service (DOS) is a general attack
as preserve the integrity, consistency and overall category in which access data is denied to intended
quality of the data [2]. users.
Database security encompasses three constructs
[1]: confidentiality, integrity, and availability. Threat 6 - Weak Authentication
 Confidentiality: Protection of data from Weak authentication schemes allow attackers to
unauthorized disclosure. assume the identity of legitimate database users by
stealing or otherwise obtaining login credentials.
 Integrity: Prevention from unauthorized data
access. 1.2 Database Security Policies
To eliminate threats, it is necessary to define
 Availability: Identification and recovery from proper security policy. Security policies are
hardware and software errors or malicious governing principles adopted by organizations [3].
activity resulting in the denial of data They capture the security requirements of an
availability. organization, specify what security properties the
system must provide and describe steps an
organization must take to achieve security.
The following list gives features of a security
policy for databases:

www.ijert.org 743
International Journal of Engineering Research & Technology (IJERT)
ISSN: 2278-0181
Vol. 2 Issue 5, May - 2013

 Access Control Policy: These policies ensure There are two classes of resources in any
that direct access to the system objects should computer system: (active) subjects and (passive)
proceed according to the privileges and the objects. The ways a subject access an object are
access rules. called access privileges. Access privileges allow
 Inference Policy: These policies specify how subjects to either manipulate objects (read, write,
to protect classified information from execute, etc.) or modify the access control
disclosure when the information is released information (transfer ownership, grant and revoke
indirectly in the form of statistical data. privileges, etc.).
 User identification/authentication policy: The access control may be based on different
This policy indicates the requirements for policies which in turn follows different principles.
correct identification of users. The user The choice of a security policy is important
identification is the basis of every security because it influences the flexibility, usability, and
mechanism. A user is allowed to access data performance of the system. The principles on
after identification as an authorized user only. which policies are based are as follows [3]:
 Accountability and audit policy: This policy  Minimum vs. Maximum privilege principle:
provides the requirements for the record According to this subjects should use the
keeping of all accesses to the database. minimum set of privileges necessary for their
 Consistency policy: This policy defines the activity. The opposite of this is maximum
state in which the database is considered valid privilege principle which is based on the
or correct and includes operational, semantic principle of maximum availability of data in a
and physical integrity of database. database.
 Open vs. Closed system principle: In an open
1.3 Database Security Models system, all accesses that are not explicitly
Security models are the formal description of forbidden are allowed. While in a closed
security policies. Security models are useful tools system, all accesses are allowed only if
for evaluating and comparing security policies [6]. explicitly authorized. A closed system is
Security models allow us to test security policies inherently more secure.
 Centralized vs. Decentralized
RT
for completeness and consistency. They describe
what mechanisms are necessary to implement a administration principle: The principle
security policy. addresses the issue who is responsible for the
Security models are described in terms of the maintenance and management of privileges in
IJE

following elements: the access control model. In centralized


 Subjects: Entities that request access to administration, a single authority controls all
objects. security aspects of the system, while in
 Objects: Entities for which access request is decentralized system different authorities
being made by subjects. control different portions of the database.
 Access Modes: Type of operation performed
by subject on object (read, write, create etc.). Access control is enforced by a reference
monitor which mediates every attempted access by
 Policies: Enterprise wide accepted security
a user to objects in the system. The reference
rules.
monitor consults an authorization database in order
 Authorizations: Specification of access
to determine if the user attempting to do an
modes for each subject on each object.
operation is actually authorized to perform that
 Administrative Rights: Who has rights in operation. Authorizations in this database are
system administration and what administered and maintained by a security
responsibilities administrators have. administrator as shown in fig 1. The administrator
 Axioms: Basic working assumptions. sets these authorizations on the basis of the security
policy.
2. Access Control Access control is different from authentication.
The purpose of access control is to limit the Authentication is a process of signing on to a
actions or operations that a legitimate user of a computer system by providing an identifier and a
computer system can perform. Access control password. So, correctly establishing the identity of
constraints what a user can do directly, as well as the user is the responsibility of the authentication
what programs executing on behalf of the users are service. On the other hand, access control assumes
allowed to do. In this way access control seeks to that authentication of the user has been successfully
prevent activity that could lead to a breach of verified prior to enforcement of access control via a
security. reference monitor.

www.ijert.org 744
International Journal of Engineering Research & Technology (IJERT)
ISSN: 2278-0181
Vol. 2 Issue 5, May - 2013

Fig 1: Access Control and Security Services

3. Discretionary Access Control (DAC) privilege p on table t, with or without grant option.
Specify the rules, under which subjects can, at Every time a privilege is revoked from a user, a
their discretion, create and delete objects, and grant recursive revocation may take place to delete all
and revoke authorizations for accessing objects to authorizations which would have not existed had
others [6]. That is: the revokee never received any authorizations for
Govern the access of users to information on the the privilege on the table from the revoker.
basis of user’s identity and predefined discretionary
rules” defined by security administrator. To illustrate this concept, consider the
The rules specify, for each user and object in the consequence of grant operations for privilege p on
system, the types of access the user is allowed for table t illustrated in fig. 2(a), where every node
the object. represents a user and an arc between node u1 and
The request of a user to access an object is u2 indicates that u1 granted the privilege on the
checked against the specified authorizations; if table to u2. The label of the arc indicates the time
there exists an authorization stating that the user the privilege was granted.
RT
can access the object in the specific mode, the
access is granted; otherwise it is denied. The Suppose now Bob revokes the privilege on the
policies are discretionary in that they allow users to table from David. According to the semantics of
IJE

grant other users authorizations to access the recursive revocation since David has never
objects. received authorization from Bob, David could not
Discretionary policies are used in commercial have granted the privilege to Ellen and Ellen to
systems for their flexibility, which makes them Jim. However in the diagram authorization from
suitable for a variety of environments with different David to Frank does not have to be deleted because
protection requirements. it may be granted by Chris. The set of
Discretionary models are applied in relational authorizations holding in the system after the
database systems using System R Authorization revocation is shown in fig. 2(b).
Model and some extensions to it.

3.1 The System R Authorization Model


This model is first defined by Griffiths and
Wade, and later revised by Fagin. Possible
relational databases privileges user can exercise on
tables are select, insert, delete and update [5].

The model supports decentralized administration


of authorizations. Any database user is authorized
to create a new table; once the table is created he
becomes the owner of the table and is fully
authorized to exercise all privileges on the table.
The owner can also grant all privileges on the table
to other users.

The authorization can be modeled as a tuple of Fig 2: Bob revokes the privilege from David
the form < s, p, t, ts, g, go> stating that the user s
has been granted privilege p on table t by user g at 3.2 Extensions to the System R Model
time ts. If go=”yes”, s has the grant option and, The previous model was extended by Wilms and
therefore, s is authorized to grant other users Lindsay to simplify the management of

www.ijert.org 745
International Journal of Engineering Research & Technology (IJERT)
ISSN: 2278-0181
Vol. 2 Issue 5, May - 2013

authorizations [6]. They have included the A Trojan horse is a computer program with an
authorizations for group. Group is a set of users or apparently or actually useful function, which
other groups. Group is disjoint i.e. a user or a group contains additional hidden functions that
may belong to more than one group. Authorizations surreptitiously exploit the legitimate authorizations
specified for group, means that they are valid for all of the invoking process. The Trojan Horse Attacks
members of the group. can be understood by the example of an
organization. Suppose a top level manager named
The two main extensions are as follows: Ann creates a table market containing sensitive
 A new type of REVOKE operation, called non- information. Tom, one of Ann’s subordinate, who
cascading is introduced. Suppose now if Bob also works secretly for another organisation wants
invokes the non-cascading revoke operation on this information. To achieve this Tom secretly
the privilege granted to David, the creates a table stolen and give write privilege to
authorization given by David to Ellen and Ann on this table. Ann doesn’t even know about
Frank are re-specified with Bob as grantor and the existence of this table and having privilege on
Jim retains the authorization given him by the table. Tom also secretly modifies worksheet
Ellen as shown in fig. 3(b). application to include two hidden operations:
 A read operation on the table market.
 The system R model uses closed world policy  A write operation on the table stolen.
under which when a user tries to access a table As shown in fig. 4(a). Tom then gives this new
and if positive authorization is not found, the application to his manager Ann. As a result during
user is denied access. The major problem with execution sensitive information is copied from
this approach is that a user does not guarantee market to stolen and becomes available to
that he will not acquire the authorization dishonest employee Tom who can now misuse this
anytime in future. The use of explicit negative information (fig. 4(b)).
authorizations can overcome this drawback.
According to which if a user has both negative 4. MANDATORY ACCESS
and positive authorization for a given privilege
CONTROL (MAC)
in the same table; the user is prevented from
RT
MAC security policies govern the access on the
using the privilege on the table.
basis of the classifications of subjects and objects
in the system [6]. Objects are the passive entries
storing information for example relations, tuples in
IJE

a relation etc. Subjects are active entities that


access the objects, usually, active processes
operating on behalf of users.
An access class consists of two components: a
security level and a set of categories.
The security level is an element of a
hierarchically ordered set. The levels often
considered are Top Secret (TS), Secret (S),
Confidential (C) and Unclassified (U), where
TS>S>C>U.
The set of categories is an unordered set, for
example, NATO, Nuclear, Army etc.
The security level of the access class associated
with an object reflects the sensitivity of the
Fig 3: Bob revokes the privilege from David information contained in the object which means
without cascade the potential damage which could result from
unauthorized disclosure of information [7]. The
3.3 Trojan Horse Attacks security level of the access class associated with a
The main drawback of DAC is that although user is called clearance, which reflects the user’s
each access is controlled and allowed only if trustworthiness not to disclose sensitive
authorized, it is possible to bypass the access information to users not cleared to it.
restrictions stated through the authorizations. A Access control in mandatory protection systems
subject who is able to read data can pass the data to is based on the following two principles:
other subjects not authorized to read the data  No read-up/ Read down: A subject can read
without the cognizance of the data owner [15]. This only those objects whose access class is
weakness makes DAC vulnerable to malicious dominated by the access class of the subject.
attacks such as Trojan Horses [6] [8].

www.ijert.org 746
International Journal of Engineering Research & Technology (IJERT)
ISSN: 2278-0181
Vol. 2 Issue 5, May - 2013

 No write-down/Write up: A subject can and Unknown (U). The integrity level associated
write only those objects whose access class with an object reflects the degree of trust that can
dominates the access class of the subject. be placed in the information stored in the object,
Satisfaction of these principles prevents and the potential damage that could result from
information that is more sensitive to flow to objects unauthorized modification of the information. The
at lower levels hence prevents the confidentiality of integrity level associated with a user reflects the
sensitive information. The effect of these rules can user’s trustworthiness for inserting, modifying or
be diagrammatically represented as shown in fig. 5. deleting data programs at that level. Principles that
are required to hold are as follows.
 Read up – A subject’s integrity level must
be dominated by the integrity level of the
object being read.
 Write down – A subject’s integrity level
must dominate the integrity level of the
object being written.
The effect of these rules can be
diagrammatically represented as shown in fig. 6.
MAC models are not vulnerable to Trojan horse
attacks: Consider fig. 4, if Tom is not allowed read
access to table Market, under MAC control, table
Market will have an access class that is either
higher than or incomparable to the access class
given to Tom. But then a subject able to read
Market would not be able to write table Stolen and
hence Trojan horse would not be able to complete
its function.

5. ROLE - BASED ACCESS


RT

CONTROL (RBAC)
In, Role-based access control (RBAC),
permissions are associated with roles, and users are
IJE

made members of appropriate roles (fig. 7). This


greatly simplifies management of permissions [16].
Roles are closely related to the concept of user
groups in access control. However, a role brings
together a set of users on one side and a set of
permissions on the other, whereas user groups are
typically defined as a set of users only.
Fig 4: Example of Trojan horse
5.1 RBAC Terminology

 Objects – Any system, resource file,


printer, terminal, database record, etc.
 Operations - An operation is an executable
image of a program, which upon invocation
executes some function for the user.
 Permissions - Permission is an approval to
perform an operation on one or more
RBAC protected objects [10].
 Role - A role is a job function within the
context of an organization with some
Fig 5: Controlling information flow for associated semantics regarding the
secrecy authority and responsibility conferred on
MAC can as well be applied for the protection the user assigned to the role.
of information integrity [7]. For example, the
integrity levels could be Crucial (C), Important (I)

www.ijert.org 747
International Journal of Engineering Research & Technology (IJERT)
ISSN: 2278-0181
Vol. 2 Issue 5, May - 2013

Fig 6: Controlling information flow for integrity

 User - A user is defined as a human being or Flat RBAC requires that user-role assignment
a process executing on behalf of a user. (UA) and permission-role assignment (PA) are
 Group - A set of users. many-to-many relations. Flat RBAC requires
 Constraint – A relationship between or support for user-role overview whereby it can be
among roles. efficiently determined which roles a given user
 Session – A mapping between a user and an belongs to and which users a given role is assigned
RT
activated sub set of the set of roles the user is to.
assigned to.
 Role Hierarchy – A partial order
relationship established among roles.
IJE

Fig 8: Flat RBAC

5.3 Hierarchical RBAC


The fig. 9 represents the Hierarchical RBAC
which differs from fig. 8 only in introduction of the
role hierarchy relation.

Role Hierarchy: Role hierarchies are a natural


means for structuring roles to reflect an
Fig 7: Role Based Access Control
organisation’s lines of authority and responsibility
[11] [12]. These hierarchies are partial orders.
5.2 Model Overview – Flat RBAC
Fig. 8 shows three sets of entities called Users
(U), roles (R) and permissions [9]. A user in this
model is a human being or other autonomous agent
such as a process or a computer. A role is a job
function or job title within the organization with
some associated semantics regarding the authority
and responsibility conferred on a member of the
role. Permission is an approval of a particular mode
of access to one or more objects in the system.
Permissions are always positive and confer the
ability to the holder of permission to perform some Fig 9: Hierarchical RBAC
actions in the system..

www.ijert.org 748
International Journal of Engineering Research & Technology (IJERT)
ISSN: 2278-0181
Vol. 2 Issue 5, May - 2013

A partial order is a reflexive, transitive and anti- in the department belong. Senior to this role are
symmetric relation. More powerful (or senior) roles roles for two projects within the department,
are shown toward the top of role –hierarchy project 1 on left and project 2 on the right. Each
diagrams, and less powerful (or junior) roles project has an engineer role senior to it. These are
towards the bottom. production and quality engineer roles. An inverted
tree facilitates sharing of resources.
 General Hierarchical RBAC
In this case there is a support for an arbitrary 5.4 Constrained RBAC
partial order to serve as the role hierarchy. The Constrained RBAC adds constraints to the
diagram below (fig. 10) shows a general hierarchy hierarchical RBAC model. Constraints may be
that facilitates both sharing and aggregation. associated with the user-role assignment (static, fig.
Within this there is a junior-most role engineering 13), or with the activation of roles within user
department and senior most role Director. In sessions (dynamic, fig. 14).
between there are roles for two projects. Each
project has a senior most role project lead 1 and 2
respectively and junior most role Engineer 1 and 2
respectively. In between each project has two
incomparable roles production engineer and quality
engineer for project 1 and 2 both.

 Limited Hierarchical RBAC


If any restriction is imposed on the structure of
the role hierarchy then we are in this case. In this
case Hierarchies are limited to simple structures Fig 12: An inverted tree Hierarchy
such as trees or inverted trees. Separation requirements are used to enforce
Fig. 11 shows a tree hierarchy in which senior conflict of interest policies that organizations may
roles aggregate the permission of junior roles. employ to prevent users from exceeding a
Thus, PL1 acquires the permission of PE1 and reasonable level of authority for their positions.
RT
QE1, and may have additional permissions of its
own. Trees are good for aggregation but do not
support sharing.
IJE

Fig 13: Constrained RBAC – Static SOD

Fig 10: A General Hierarchy

Fig 14: Constrained RBAC – Dynamic SOD

Fig 11: A Tree Hierarchy Separation of duty refers to the partitioning of


Fig. 12 shows an inverted tree hierarchy. There tasks and associated privileges among different
is a junior – most role ED to which all employees roles so as to prevent a single user from gathering

www.ijert.org 749
International Journal of Engineering Research & Technology (IJERT)
ISSN: 2278-0181
Vol. 2 Issue 5, May - 2013

too much authority. Separation of duty is of two [2] Meg Coffin Murray, “Database Security: What
types: students need to know”, Journal of Information
 Static Separation of Duty Technology Education: Innovations in Practice,
Volume 9, 2010, pp. 61-77.
The static separation of duty is also called strong
exclusive which states that “A principal may not be [3] A. B. Dastjerdi, J. Pieprzyk, and R. S. Naini. ,
member of any two exclusive roles” [13]. It means “Security in Database: A Survey Study”,
that the user is authorized of one role may not be Department of Computer Science, The University of
authorized of another role or two roles have no any Wollongong, 1996, pp. 1- 39.
shared principle.
[4] Emil Burtescu, “Database Security- Attacks and
 Dynamic Separation of Duty Control Methods”, Journal of Applied Quantitative
Methods, Volume 4, No. 4, 2009, pp. 449-454.
The Dynamic separation of duty is also called
weak exclusive which states that “A principal may [5] E. Bertino, S. Jajodia and P. Samarati, “Database
be a member of any two exclusive roles but must Security: Research and Practice”, Pergamon,
not activate them both at the same time” [13]. So, Information Systems, Volume 20, No. 7, 1995, pp.
the user is authorized of both roles but both roles 537-556.
cannot be active at the same time.
[6] R. Dollinger, “Database Security Models- A Case
Study”, European Symposium on Research in
 Principle of Least Privilege
Computer Security, 1990, pp. 35-41.
Within RBAC system separation concepts are
supported by the principle of least privilege. [7] R. Sandhu and P. Samarati, “Access Control:
The principle of least privilege requires that a Principles and Practice”, IEEE, Communications
user be given no more privilege than necessary to Magazine, 1994, pp. 40-48.
perform a job [13]. Ensuring least privilege
requires identifying what the user's job is, [8] R. A. Crues, “Methods for Access Control:
determining the minimum set of privileges required Advances and Limitations”, Harvey Mudd College,
to perform that job, and restricting the user to a Claremont, California.
domain with those privileges and nothing more.
RT
[9] Sandhu, Ravi, David Ferraiolo, and Richard Kuhn,
“The NIST model for role-based access control:
6. Conclusion Towards a unified standard”, Symposium on Access
Database security is an important goal of any Control Models and Technologies, Proceedings of
IJE

data management system. Database security is the fifth ACM workshop on Role-based access
based on three important constructs confidentiality, control, Volume 26, No. 28, 2000, pp. 47- 63.
integrity and availability. Access control maintains [10] R. Sandhu and E. J. Coyne, “Role-Based Access
a separation between users on one hand and various Control Models”, IEEE Computer, 1996, pp. 38-47.
data and computing resources on the other. There
are three main models of access control: DAC [11] R. Sandhu, E. J. Coyne H. L. Feinstein and C. E.
model govern the access to data on basis of user’s Youman, “Role – Based Access Control Models”,
identity predefined rules but are vulnerable to IEEE Computer, Volume 29, No. 2, Februaryn1996,
Trojan horse attacks. MAC models govern the pp. 38-47.
access by users to data on the basis of
[12] S. L. Osborn, “Role- Based Access Control”,
classifications assigned to them but are too rigid to
Springer, Security, Privacy, and Trust in Modern
some environments. In RBAC models regulate Data Management, 2007, pp. 55-70.
access on the basis of roles user play in a system.
Roles can be defined as set of actions or [13] D. F. Ferraiolo and R. Kuhn, “Role – Based Access
responsibilities associated with a particular Control”, 15th National Computer Security
working activity. RBAC makes the management of Conference, Baltimore, 1992, pp. 554-563.
permissions easier, supports for principle of least
privilege, separation of duties etc. All the models [14] Huwida., M. Guimaraes, Z. Maamar, and L.
are not perfect and have their own vulnerabilities Jololian, “Database and Database Application
Security”, ACM SIGCSE Bulletin, Volume 41, No.
thus must be chosen according to the needs of
3, 2009, pp. 90-93.
organizations.
[15] S. Imran, Dr. I. Hyder, “Security Issues in
7. References Databases”, IEEE, Second International Conference
on Future Information Technology and Management
[1] E. Bertino and R. Sandhu, “Database Security – Engineering, 2009, pp. 541-545.
Concepts, Approaches and Challenges”, IEEE
Transactions on Dependable and Secure Computing, [16] J. Zheng, Q. Zhang, S. Zheng and Y. Tan,
Volume 2 , No. 1, January- March ,2005, pp. 2-16. “Dynamic Role-Based Access Control Model”,

www.ijert.org 750
International Journal of Engineering Research & Technology (IJERT)
ISSN: 2278-0181
Vol. 2 Issue 5, May - 2013

JOURNAL OF SOFTWARE, Volume 6, NO. 6,


JUNE 2011, pp. 1096-1102.

[17] Li N., J. Byun, and E. Bertino, “A critique of the


ANSI standard on role-based access control”,
Security & Privacy, IEEE Volume. 5, no. 6, 2007,
pp. 41-49.

[18] D.F. Ferraiolo, R. Sandhu, S. Gavrila, D. Richard


Kuhn, and R. Chandramouli, “Proposed NIST
standard for role-based access control”, ACM
Transactions on Information and System Security
(TISSEC), Volume 4, No. 3, 2001, pp. 224-274.

[19] T. F. Lunt and E. B. Fernandez, “Database


security”, ACM SIGMOD Record 19, No. 4, 1990,
pp. 90-97.

RT
IJE

www.ijert.org 751

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy