Logical access controls can be based on one or more criteria, including:
You should take each of these criteria into account when designing an authorization system.
The “who” criterion is the most intuitive, as discussed above. One subject may be given access while another is denied.
The decisions made by authorization systems must also factor in the type of access being requested by the end user. The object of the authorization request is significant. For example, you might create different access controls around a customer price list on one hand and a listing of your top 10 accounts and the revenue generated from each on the other.
Time profiles can be a useful way to prevent an authorized user from using resources for unofficial purposes. For example, an employee may be legitimately authorized to use a network printer, but it should raise questions if that employee begins to print jobs outside of normal business hours. This could mean that the employee is working overtime, or it could be an indication that he or she is using company resources for personal projects. Time profiles are also used when a user has a limited amount of time to perform an action. For example, a journalist may only have until 1 p.m. to submit his or her story for the evening newscast. Restricting the journalist’s access to the story submission system after 1 p.m. prevents the journalist from turning in the story late and forcing the editing staff to scramble to fit the story in.
If you must use time profiles to meet business needs, design the system to be easy to modify for special cases such as overtime or a breaking news story.
Location can be another way to ensure that only authorized users access resources, and that those users are performing legitimate tasks. You can determine location either logically or physically.
“Why does this user need access to this resource?” This is a question you should ask every time you design a set of access controls. Every user should have a well-defined purpose related to his or her job function in order to gain access to resources.
“Logical location” refers to the Internet Protocol (IP) address or Media Access Control (MAC) address a user connects from.
“Physical location” is more obvious—within a certain building or secured facilities. If a user attempts to access resources from his or her corporate laptop on the company network, the system grants access. The same user could try to access those resources from his or her home PC and be denied. This type of restriction is often used with highly sensitive information. If an employee decided to work from the local coffee shop and accessed a confidential file, another patron at the coffee shop could “sniff” that transmission and gain access to confidential information. Restricting access by location ensures that sensitive data is sent only over trusted, secure networks.
Once you evaluate all of the above criteria, you can determine how the user will access a resource, that is—what type of access you need to grant. There are four basic access levels:
In some systems, you can define these four access levels with more granularity, but every system includes them.
Access controls may often be more efficiently managed through the use of role-based groups. This is especially true in large organizations. Rather than deciding and assigning rights to each individual within an enterprise, you cluster individuals into groups based on department, job title or role, or some other classification.
Granting access by groups rather than individuals does not reduce individual accountability for activities. An individual still needs to log in with a unique username and password, and the log files catalog actions by username, not by group.
You can assign individuals to several groups. For example, every person within an enterprise may be a member of the Employees group, with read access to the company Intranet and an account on the time card system. A manager might also be a member of the Managers group and have write access to his or her department’s page on the Intranet as well as read access to each of his group’s time card reports. Employees on the corporate retreat committee would have their normal levels of access as well as access to files related to the corporate retreat, regardless of their other job functions. A manager might not have access to those files, despite the fact that employees below him do.
Group access rights are a way of simplifying the management of the rules. When an employee changes roles within an organization, you merely have to change his or her group membership rather than altering the employee’s individual access rights. Similarly, when you create a new resource and want to grant access to a particular role, you can do that using the group mechanism and you don’t need to list all of the individual employees.
So far, you have focused primarily on subjects and access controls. Now you will examine how objects fit into access controls. The biggest difference between a subject and an object is passivity. A subject is active—it acts upon a passive object. An object must contain something of interest to the subject. This is usually information, but can be noninformational as well. Consider a printer. It is passive in that it is the target of a print request and does not generally initiate new contact with the subject after the print job is complete. It contains, or rather produces, something of value—a hard copy of digital information. Printers, however, do not usually have a high level of granularity. They receive a print request and process it. A server, however, can have many elements that must work together to supply the subject with the information it requests.
You can define objects at many levels, depending on your business needs. Some examples of objects include:
In real-world applications, these levels may work together or separately to provide access rights to resources. A simple example is an application (in this case, the application is the subject) that needs to work with data stored in the database (the object). It makes a request through an application programming interface (API), which handles the communication between the application and the database.
A more complex example is that of a user who needs to modify a data file stored on a file server across the network (FIGURE 1-3). In this case, the user (subject) logs into the operating system (object 1) and requests access to the file server across the network (object 2). The system layer on the file server (object 3) checks the user’s credentials against its rules to determine if the user has no access, read-only, read/write, or administrative access to the particular data file requested.