Chapter 8. Access Control

One of the most fundamental concepts in the world of digital identity is access control. Access control is the process of granting certain subjects access to a resource while denying others access. Even the notion of granting access is too coarse-grained—in many cases, we must control what actions a subject is allowed take on a resource. Some examples:

We've seen in Chapter 7 how authentication can be performed to certify a set of credentials and their associated identity. Our ultimate goal, however, is to use that identity to control the actions that subjects can take on resources. This is called access control, and it is based on determining a set of authorizations for a given identity. In this chapter, we'll explore some of the issues, patterns, and technology surrounding access control.

Access control is first and foremost a policy question. Access-control technology is designed to automatically enforce the policy. Policy is a reflection of business and security objectives that have been set in accordance with other organizational policies, the generally accepted practices of industrial and professional organizations, regulatory and legal requirements, and organizational goals.

Here are some simple examples of access-control policies:

  • Everyone is allowed to read this folder and its contents.

  • All users who have been authenticated can read and write to this folder and its contents.

  • User "Bob" is allowed to read and write table "orders" in database "sales."

  • All users in the marketing department can read the marketing materials on the internal web server.

  • HR employees who are managers or above can modify salaries during working hours as long as they are accessing the salary application from the corporate LAN.

I've purposely ordered this list so that the policies progress from simple and specific to complex and abstract. The first, for example, is relatively straightforward to implement. Some of these policies talk about the user's role rather than identifying specific users ("manager," is a role, for example).

The last policy assumes that we can not only identify which employees work in HR but what their grade is and when "working hours" are. Are working hours 8 to 5? Does it change with each employee? Can we reliably tell who is accessing the system from the corporate LAN? There are business and technology aspects to these questions; some have both. For example, the idea of working hours is a business concept, but we also have to ask if the access-control infrastructure can support locking users out of resources based on the time of day.

The most important questions in access control have to do with responsibility. We typically classify that responsibility into three categories: owners , custodians , and users. The owner of the resource may be the person who created it, the head of the organization that owns it, or some other person or role. Ownership can be delegated or assigned. When you can't figure out who owns a resource, the natural default is the organization itself.

Access control is more effective when owners are explicitly designated, because they will be the ones with ultimate decision making authority and the responsibility for ensuring resources under their control are appropriately accessed. In government organizations, it is not unusual for owners to be designated in statute or by regulation. Your organization may not be as legalistic, but specifically designating owners and holding them responsible is an important part of information security.

Custodians are those people who actually manage the resources day to day. Every person in the organization is likely the custodian for some set of resources. Custodians are responsible for ensuring that access-control policies are enforced and that resources are available for use by authorized users. Often the custodian and the owner for a particular resource are the same person when the resource is a document or other information created in the course of day-to-day work. Someone other than the owner usually maintains larger resources, such as databases and web sites.

Custodians also play an important role in access control, because they are the ones that will implement and monitor the access-control policies that the owner specifies. Often, custodians are system administrators or technical operations personnel. Custodians have significant responsibility and are often entrusted with numerous resources. Also, custodians usually have "superuser" powers and can access any resource under their purview. Consequently, it's important to choose custodians with care and build identity infrastructures that allow cross-checks and auditing of custodial actions.

A user is the person, group, corporation, software program, or other entity that wants access to resources. Users might be the customers or employees of the organization that owns the resource. They might also be the employees, or even the customers, of partners and suppliers. Users might be responsible for ensuring that a resource is protected while in use, becoming custodians for a time. Often, access-control systems do not or cannot have the level granularity to protect a resource completely and so it becomes the responsibility of the user to act in accordance with the owner's instructions.

As an example, most document-management systems can control access to the document itself but not individual parts of the document. The owner of a document might share it with a co-worker with specific instructions about what sections can be modified and which cannot. The co-worker, as a user of the resource, has responsibility to treat the document in accordance with the owner's instructions, but these cannot be enforced by the access-control system.

Seeing the limitations of the principle of least privilege leads to a second principle to guide the development of access-control policies: accountability scales better than enforcement. The simplest access-control policies to implement are based on trust and accountability. User actions are logged, and the logs are audited. When the logs show an unauthorized access by a user, appropriate action is taken. Accountability is a log-processing problem that can be done offline by a separate system and thus scales very well.

As an example, consider the problem of documents shared by email. You probably have no idea whether any of your employees are using the corporate email system to send important, even vital, company secrets to your competitors. The traditional approach to this problem is to try to create some sort of access-control infrastructure that requires permissions and authentication in order to email documents outside the company. This is largely impractical.

But a system to solve this problem based on accountability is practical. Creating a system that logs email to the outside world, notes any with attachments, and records the sender, date, and a hash of the document is fairly easy to do. You may not be able to stop the document from being sent, but you will at least know about it and be able to take steps to recover.

Obviously, real-world scenarios cannot accept the risk of an access-control policy based solely on accountability. But accountability can augment the access-control policy to provide protections that are difficult or expensive using traditional permissions-based access control . Organizations should carefully consider where the risk can be tolerated, because accountability-based systems are considerably cheaper to implement and operate than enforcement systems.