Database Controls

41
DATABASE CONTROLS SUSAN MAHAKATA R0434545 PATRICK MAPURANGA R0538687 NDAIZIVEI KANGAMBEU R146884J

description

audit

Transcript of Database Controls

DATABASE CONTROLS

DATABASE CONTROLSSUSAN MAHAKATA R0434545PATRICK MAPURANGA R0538687NDAIZIVEI KANGAMBEU R146884JACCESS CONTROLSFrom (ISC)2 Candidate Information Bulletin:Access control is the collection of mechanisms that permits managers of a system to exercise a directing or restraining influence over the behavior, use, and content of a system. It permits management to specify what users can do, which resources they can access, and what operations they can perform on a system.ACCESS CONTROLSAccess Controls: The security features that control how users and systems communicate and interact with one another.Access: The flow of information between subject and objectSubject: An active entity that requests access to an object or the data in an objectObject: A passive entity that contains informationACCESS CONTROLSChoosing a security policyName dependent access control policyContent dependent controlContext dependent access control policyHistory dependent access control policyACCESS CONTROLSChoosing a security policy Database Security can be defined as protecting information against unauthorized disclosure, alteration or destruction using hardware or software techniquesAccess Control Policies are used for securing databases. It ensures data confidentiality, integrity and availabilityDifferent policies can be combined to provide a more suitable protection to database systemThere are two main access control policies - Mandatory Access Control Policy and Discretionary Access Control Policy. In modern age new access control policy -Role Base Access Controlis used. The RBCA is most popular access control model and has been used in various applications e.g. in grid and multilevel databases Security System.ACCESS CONTROLSChoosing a security policy

DISCRETIONARY ACCESS CONTROL POLICY Discretionary protection policies govern the access of users to the information on the basis of the users identity and authorizations. These authorizations are also known as rules. These rules specify the access modes, for each user (or group of users) and each object in the system.Can be referred as a means of restricting access to objects based on the identity of subjects and/or groups to which they belong. This policy places the decision of who can access information at the discretion of the information creator i.e. owner of data or database administrator.Security policy implementation is based on granting and revoking privileges. Access is granted or denied based on the identification of the userACCESS CONTROLSChoosing a security policy

Mandatory Access Control (MAC) constrains the ability of a subject (i.e. user) to access or generally perform some sort of operation on an object. MAC policy requires all users to follow the rules of access set up by the Database Administrator (DBA). This policy needs objects (e.g. Database) to be classified and subjects (e.g. Users, Process) to be cleared.It restricts access to objects based on the sensitivity of the information. It also provides an environment that restricts users to sharing information only within the same project, department or organization. Access control is based on the two principles, No read-up and No Write-down. This prevents information in a sensitive object from flowing, through either read or write operations, into objects at lower or incomparable access classesACCESS CONTROLSChoosing a security policy

Role-based policiesRegulate users access to the information on the basis of the activities the users execute in the system i.e. RBAC models are based on the notion of role.A Role represents a specific function within an organization and can be seen as a set of actions or responsibilities associated with this function.Under an RBAC model, all authorizations needed to perform a certain activity are granted to the role associated with that activity, rather than being granted directly to users. Users are then made members of roles, thereby acquiring the roles authorizations. Thus user access to objects is mediated by roles; each user is authorized to play certain roles and, on the basis of these roles, a user can perform accesses to the objectsACCESS CONTROLSAccess Control Techniques

There are a number of different access controls and technologies available to support the different models.Name Dependent Access ControlHistory Dependent Access ControlContent Dependent Access ControlContext Dependent Access ControlACCESS CONTROLSAccess Control Techniques

Content Dependent Access Control: Access to an object is determined by the content within the object.eg you can only see salaries less than 50K, or you can only see salaries of employees who report to youHistory Dependent Access Control: access is decided based not only on the current request, but also on the previous history of accesses to some entity or service.ACCESS CONTROLSAccess Control Techniques

Context Based Access Control: Makes access decision based on the context of a collection of information rather than content within an object.eg salary information can be updated only at year endthe company's earnings report is confidential until announced at the stockholders meetingyou cannot access classified information via a remote loginConcurrency ControlsNature of a shared data resourceProblem Of deadlockSufficient Conditions for a deadlockSolutions to deadlockPreventing Deadlock

Shared Resource Example Of a BridgeTraffic only in one direction.Each section of a bridge can be viewed as a resource.If a deadlock occurs, it can be resolved if one car backs up (preempt resources and rollback).Several cars may have to be backed up if a deadlock occurs.Starvation is possible.Problem Of deadlockA set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the setExample System has 2 disk drivesP1 and P2 each hold one disk drive and each needs another oneExample semaphores A and B, initialized to 1 P0 P1wait (A);wait(B)wait (B);wait(A)

Sufficient Conditions for a DeadlockMutual exclusion: only one process at a time can use a resource.Hold and wait: a process holding at least one resource is waiting to acquire additional resources held by other processes.No preemption: a resource can be released only voluntarily by the process holding it, after that process has completed its task.Circular wait: there exists a set {P0, P1, , P0} of waiting processes such that P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is held by P2, , Pn1 is waiting for a resource that is held by Pn, and P0 is waiting for a resource that is held by P0.

Deadlock can arise if four conditions hold simultaneously.System ModelResource types R1, R2, . . ., RmCPU cycles, memory space, I/O devicesEach resource type Ri has Wi instances.Each process utilizes a resource as follows:request use release16Draw p0 and p1 accessing 2 nonesharable resources (semaphores)Wait(a); wait(b).wait(b); wait(a)Resource-Allocation GraphV is partitioned into two types:P = {P1, P2, , Pn}, the set consisting of all the processes in the system.

R = {R1, R2, , Rm}, the set consisting of all resource types in the system.request edge directed edge P1 Rjassignment edge directed edge Rj PiA set of vertices V and a set of edges E.Resource-Allocation Graph (Cont.)Process

Resource Type with 4 instances

Pi requests instance of Rj

Pi is holding an instance of RjPiPiRjRjExample of a Resource Allocation Graph

Resource Allocation Graph With A Deadlock

Resource Allocation Graph With A Cycle But No Deadlock

Basic FactsIf graph contains no cycles no deadlock.

If graph contains a cycle if only one instance per resource type, then deadlock.if several instances per resource type, possibility of deadlock.Methods for Handling DeadlocksEnsure that the system will never enter a deadlock state.

Allow the system to enter a deadlock state and then recover.

Ignore the problem and pretend that deadlocks never occur in the system; used by most operating systems, including UNIX.Deadlock PreventionMutual Exclusion not required for sharable resources; must hold for nonsharable resources.

Hold and Wait must guarantee that whenever a process requests a resource, it does not hold any other resources.Require process to request and be allocated all its resources before it begins execution, or allow process to request resources only when the process has none.Low resource utilization; starvation possible.Restrain the ways request can be made.Deadlock Prevention (Cont.)No Preemption If a process that is holding some resources requests another resource that cannot be immediately allocated to it, then all resources currently being held are released.Preempted resources are added to the list of resources for which the process is waiting.Process will be restarted only when it can regain its old resources, as well as the new ones that it is requesting.

Circular Wait impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration.

Deadlock AvoidanceSimplest and most useful (??) model requires that each process declare the maximum number of resources of each type that it may need.

Resource-allocation state is defined by the number of available and allocated resources, and the maximum demands of the processes.

The deadlock-avoidance algorithm dynamically examines the resource-allocation state to ensure that there can never be a circular-wait condition.

Requires that the system has some additional a priori information available.Safe StateWhen a process requests an available resource, system must decide if immediate allocation leaves the system in a safe state.

System is in safe state if there exists a safe sequence of all processes.

Sequence is safe if for each Pi, the resources that Pi can still request can be satisfied by currently available resources + resources held by all the Pj, with j