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 want to grant each employee access to his email box, but not to anyone else's. Email administrators are granted access to everyone's email accounts.
The bank grants me access to my bank account but limits that access in certain ways. For example, I can only withdraw up to some preset limit at the ATM. My wife has access to the same account. Bank employees have access to the account but only in controlled situations.
The software I use to manage my web site has access to the web site and can create new files and delete or update existing ones. Anyone is granted access to the files for reading.
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.
One of the fundamental ideas on which access-control policies are founded is the principle of least privilege. This principle simple says that users should be given no more access to resources than they need to accomplish necessary functions. Least privilege is a good guideline to follow in creating policy and makes some decisions easier, but in practice, it has limitations that are not easily overcome by real-world authorization systems:
Implementing least privilege requires extremely fine-grained permissions. Essentially, every action that might ever be taken by any user on any resource needs a permission defined.
The types and levels of authorization necessary to perform a given task may change over time.
Any given individual will need different levels of privilege depending on the task she is currently performing.
These limitations have led to systems that implement least privilege imperfectly, sometimes to ill effect. We'll see examples of this later in this chapter.
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.