A Multi-Layered Privilege Model
Issues relating to access apply not only to the web application itself but also to the other infrastructure tiers which lie beneath it — in particular, the application server, the database, and the operating system. Taking a defense-in-depth
approach to security entails implementing access controls at each of these layers to create several layers of protection. This provides greater assurance against threats of unauthorized access, because if an attacker succeeds in compromising defenses at one layer, the attack may yet be blocked by defenses at another layer.
In addition to implementing effective access controls within the web application itself, as already described, a multi-layered approach can be applied in various ways to the components which underlie the application, for example:
■ The application server can be used to control access to entire URL paths, on the basis of user roles that are defined at the application server tier.
■ The application can employ a different database account when carrying out the actions of different users. For users who should only be querying (and not updating) data, an account with read-only privileges should be used.
■ Fine-grained control over access to different database tables can be implemented within the database itself, using a table of privileges.
■ The operating system accounts used to run each component in the infrastructure can be restricted to the least powerful privileges that the component actually requires.
In a complex security-critical application, layered defenses of this kind can be devised with the help of a matrix defining the different user roles within the application and the different privileges, at each tier, that should be assigned to each role. Figure -1 is a partial example of a privilege matrix for a complex application.
Figure -1: Example of a privilege matrix for a complex application
Within a security model of this kind, you can see how various useful access control concepts can be applied:
■ Programmatic control — The matrix of individual database privileges is stored in a table within the database, and applied programmatically to enforce access control decisions. The classification of user roles provides a shortcut for applying certain access control checks, and this is also applied programmatically. Programmatic controls can be extremely fine-grained and can build in arbitrarily complex logic into the process of carrying out access control decisions within the application.
■ Discretionary access control (DAC) — Administrators are able to delegate their privileges to other users in relation to specific resources that they own, employing discretionary access control. This is a closed DAC model, in which access is denied unless explicitly granted. Administrators are also able to lock or expire individual user accounts. This is an open DAC model, in which access is permitted unless explicitly with drawn. Various application users have privileges to create user accounts, again applying discretionary access control.
■ Role-based access control (RBAC) — There are named roles, which contain different sets of specific privileges, and each user is assigned to one of these roles. This serves as a shortcut for assigning and enforcing different privileges and is necessary to help manage access control in complex applications. Using roles to perform upfront access checks on user requests enables many unauthorized requests to be quickly rejected with a minimum amount of processing being performed. An example of this approach is in protecting the URL paths that specific types of user may access.
When designing role-based access control mechanisms, it is necessary to balance the number of roles so that they remain a useful tool to assist in the management of privileges within the application. If too many fine grained roles are created, then the number of different roles becomes unwieldy, and they are difficult to manage accurately. If too few roles are created, the resulting roles will be a coarse instrument for managing access, and it is likely that individual users will be assigned privileges that are not strictly necessary for performance of their function.
■Declarative control — The application uses restricted database accounts when accessing the database. It employs different accounts for different groups of users, with each account having the least level of privilege necessary for carrying out the actions which that group is permitted to perform. Declarative controls of this kind are declared from outside the application. This is a very useful application of defense-in-depth principles, because privileges are being imposed on the application by a different component. Even if a user finds a means of breaching the access controls implemented within the application tier, so as to perform a sensitive action such as adding a new user, they will be prevented from doing so because the database account that they are using does not have the required privileges within the database.
A different means of applying declarative access control exists at the application server level, via deployment descriptor files, which are applied during application deployment. However, these can be relatively blunt instruments and do not always scale well to manage fine grained privileges in a large application.
NEXT is..Injecting Code…………,.,.,.,.,.,.,.,.,
