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.

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.

“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:

• Administrative—The ability to read, write, create, and delete files
• Author—The right to read and write his or her own files
• Read only—Can read but not edit files
• No access—Complete denial of access

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.

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:

• Data element—This is the lowest level of granularity for information-based assets. For example, if a database table contains a Social Security number, you may need to place special restrictions on that data element.
• Table—You may also define a database table as an object. You could grant users access to tables containing employment information, order information, or other types of information based on their roles in the organization.
• Database—You can also define an entire database as an object. For example, you might grant all employees read-only access to the entire product information database and give product managers write access to certain tables or rows within that database.
• Application—An application is also an object. You might wish to grant some users the ability to run an application while denying it to other users. Applications may also implement their own access control systems that restrict use of individual components of the application. For example, an administrative user within the application may see a menu that allows them to add or delete other users. A basic user would see this menu and would not have access to that functionality within the application.
• System—A system is also a security object. For example, you may restrict access to the CEO’s laptop so that only the CEO and his or her administrative assistant have permission to log on to it.
• Operating system—This provides various user modes, such as privileged or superuser mode, user mode, and guest mode. It also governs configuration files and log files. The operating system also provides write protection on files, subdirectory permissions, and restrictions on the ability to create, delete, access, or execute new files or directories.
• Network—This provides access restrictions for resources stored on the network or on a subnetwork. It provides the ability to traverse network connections and restricts external access, either inbound or outbound.

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.