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 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.
Policy First
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.
Responsibility
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.
Principle of Least Privilege
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.
Accountability Scales Better than Enforcement
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.
Authorization Patterns
Real-world systems live somewhere in between a perfect enforcement of least privilege and a system based solely on accountability. As computing and networking technology has matured, a variety of access-control schemes have been developed to try to balance these needs. These schemes represent broad philosophical frameworks that aid the development of access control policies as well as specify implementations for a particular scheme.
In practice, most organizations use a hybrid approach to access control where the resource owner tightly controls certain resources and custodians control other resources. For example, most organizations control access to the HR system in a very formal way, while allowing individual employees to determine who will see documents that they produce within some very broad guidelines.
Mandatory and Discretionary Access Control
One of the first organizations to systematically look at access control on computer systems was the Department of Defense. A 1983 Department of Defense publication called the Trusted Computer System Evaluation Criteria (TCSEC), but commonly referred to as “the orange book” because of the color of its cover, defined two modes of access control for the Department of Defense: mandatory access control and discretionary access control. In mandatory access control (MAC), the owner (or the owner’s representative) sets the policy, and custodians and users are obligated to follow it. In discretionary access control (DAC), the custodian is left to determine what users will be granted access. Further, once granted access, the user becomes, in effect, a custodian, because a user can grant access to other users.
There has been a significant body of research on military security standards with some important discoveries. One of the most important is an undecidability result that showed that a DAC-based system, judged to be initially safe with respect to some policy, cannot be shown to remain safe over time. User actions may eventually result in an unauthorized user being granted access.
Another important result involves what is known as “tapping-out information.” Consider a system where there are two levels of access control: classified and unclassified. In any system with shared resources between access-control levels (e.g., classified and unclassified documents stored on the same filesystem), it is impossible to keep users of classified information from sharing that information with unclassified users. In short, enforcing MAC on a shared system is impossible, because users with access to classified data can always find ways to encode classified information in system resources. Since these resources can be viewed by both sets of users, unclassified users can decode the message and see classified data. For example, if both sets of users can see the filesystem, classified data could be encoded by manipulating the presence of a particular file or even just its size, over time.
These results may seem somewhat esoteric, but taken together, they lead to a fundamental and important conclusion: you cannot build a practical access-control system that does not rely, to some extent, on trusting custodians and users to follow the policies.
User-Based Permission Systems
Perhaps the best known and most widely used access-control scheme is a user-based permission system made popular by the Unix file permission system. Figure 8-1 shows a schematic representation of how user and group permissions work in this system. The system is conceptually simple: both users and groups have access rights to resources directly and users belong to groups.
As embodied in the Unix filesystem , there are three permission levels: read (r), write (w), and execute (x). These permission levels are applied as attributes of the files and directories on the system. For simplicity, we’ll just speak of files here, but the concepts are just as applicable to directories.
Files belong to owners, specific Unix users on the system, and groups, collections of users. Each of these levels can be set for the file’s owner, the file’s group, and everyone else. So for example, it possible to set permissions on a file so that it is readable and writable by its owner and only readable by its group and not readable by everyone else. Just about any other combination you can imagine is possible as well.
User-based permission systems are fairly simple to use and administer, and they have served nicely for decades. Still, they suffer from several drawbacks:
Most users ignore groups altogether and few understand them because user-interface issues in Unix make using groups problematic. For example, each user in a group can own files and, as a consequence, control the permissions. But when users create files meant for the group, they often forget to set group permissions correctly, resulting in a flurry of emails asking that the owner fix the group permissions.
More problematic is the inflexibility of the group system. Since only one group owns a file, it is difficult to create a set of files that can be accessed by multiple groups. The only way to do this is to create a third group and put everyone in the other two groups into the new group. But because groups cannot contain groups, if the membership of one of the subordinate groups is changed, the third group would not be updated automatically.
Groups also work best for long-standing file-sharing relationships. If you only want to quickly share a file with someone, creating a new group, adding both users to the group, and making the file owned by the new group is considerable overhead. Also, on most systems, creating groups requires superuser authority, so most users can’t do it.
There are few tools for managing groups, other than editing text files, and the commands that users have to issue to set up group shared directories are somewhat arcane, even for Unix users.
Probably the most difficult problem to overcome in this system is the fact that because both users and groups have access to resources, merely deleting a group does not necessarily delete the permissions of the users of the group to access the resource. In fact, because the permissions are associated directly with the resource, it is almost impossible to determine what resources any given user has access to.
All of this has combined to cause system designers to search for something more flexible and easier to understand and use.
Access-Control Lists
Access-control lists (ACLs) are an attempt to create a more flexible permissions system that grants individual users access to specific resources. Access-control lists are just exactly what they sound like: lists of specific users and groups who have access to the resource. In filesystems, ACLs are stored as attributes of the files and encompass the standard file-permissions system and expand it to enable specific users or groups to be designated as having a particular level of access.
Figure 8-2 shows a schematic representation of access-control lists. The primary difference between this diagram and Figure 8-1 is the insertion of a permissions structure between the resources and the users and groups. Rather than users and groups being directly associated with a given resource, the resource has a set of permissions that includes both users and groups. This indirection gives ACL-based permission systems additional flexibility at the cost of some additional complexity.
Because ACLs are a recent addition to many operating systems, many tools and applications do not support them fully, if at all. More problematic is the fact that permissions are stored as attributes of the resources and are thus distributed across the filesystem, making managing individual user access difficult. For example, when a user no longer requires access to a set of resources due to a job change or a process change, there is no single place where those permissions can be changed. The resources must be visited one by one, and permissions for that user removed.
Role-Based Access Control
Role-based access control (RBAC) is based on the idea that users are typically granted access to resources based on their roles in the organization. Figure 8-3 shows a schematic representation of RBAC.
A key feature of the RBAC model is that all access is through roles. Contrast this with the user-based permission model shown in Figure 8-1. In the RBAC model, some authority, such as the HR department, assigns roles and the resource owner assigns permissions.
A second key feature of RBAC-based authorization is that roles can be hierarchical, as shown in Figure 8-4. If roles are created as shown in this figure, assigning an employee a role as a developer also automatically assigns roles as a member of the engineering department and as an employee. In addition to being hierarchical, roles can be parameterized to aid in role administration.
Role-based authorization schemes are based on three rules:
Role assignment. All users of the system are assigned roles; users without roles cannot take any action.
Role authentication. Before a user can take on a role, that role must be authenticated for that user.
Action authorization. A user can take an action only if that action is authorized for the current, authenticated role of the user.
Role-based authorization is more flexible than an authorization scheme based on simple groups and more secure than one in which users can be authorized independent of their group or role membership. Furthermore, as practiced, role-based authorization makes it relatively easy to add and remove a user’s access to resources as his function in an organization changes, even if he changes tasks day to day.
Abstract Authorization Architectures
In designing identity systems, we typically talk about two abstract places where authorization decisions are made: the policy enforcement point (PEP) and the policy decision point (PDP). Figure 8-5 shows a PEP and PDP in action.
The PEP is the point in the system where the user requests access to a resource. For example, if a user attempts to access a web page, the web server is the PEP. The PDP is the point in the system where the decision is made as to whether or not the user will be allowed to access a resource. In many cases, the PDP is part of the same system that houses the PEP, but it needn’t be. The web server could, for example, send the resource name (a URL, in this case) and the user ID to a separate system and simply get back a “yes” or “no” answer. Note that this is different from the web server asking another server to authenticate a user. That is an authentication question, not one of authorization.
Even when the PEP and the PDP are co-located in the same system or program, it is useful to see authorization as a coordinated effort between these two abstract systems. The PDP makes its determination of entitlements or permissions based on an access policy that has been set in advance.
When a PDP makes a determination regarding a particular subject’s right to access a particular resource, the decision is called an authorization decision assertion (ADA). An ADA can take any form that the PEP and PDP can agree on. We’ll discuss standards for communicating ADAs as well as storing access-control policies in Chapter 11.
Digital Certificates and Access Control
We’ve seen how digital certificates can be used in an authentication infrastructure. Because the certificate is just a data structure that can be extended, it can also be used to store permissions and other authorization information, such as roles. The signature of the certificate authority ensures that these attributes can’t be tampered with. The use of certificates in this way makes two important assumptions:
The roles, permissions, and entitlements regarding the subject of the certificate are static, and thus can be encoded in a certificate that is updated infrequently.
The chain of trust from the organization to the certificate authority is such that systems needing to use the permissions in the certificate can trust that they were set in accordance with the correct access-control policy.
The inflexibility of this system is its chief drawback. Changing access-control permissions requires revoking the old certificate and issuing a new one. Its primary strength is that permissions move with the certificate in a trustworthy way, negating the need for a complicated database infrastructure to store the permissions.
Conclusion
Authorization complements authentication to form the basis for access control. In many ways, authorization is the focal point around which the enterprise identity management infrastructure revolves.
The pressures to expand authorization systems to cover more and more fine-grained resources in the enterprise is a natural outgrowth of the drive to align IT systems more fully with business purposes. These pressures lead to extremes in system complexity, however, unless they are managed and thought through carefully. The final section of this book will help you develop a strategy that will allow you to derive the most value from your identity management investment.