Brunel Home EuroView Home Deliverables

7. Security Policy

Whether you decide to permit external connections to your directory or not, access restrictions of some form will have to be applied. Database administrators will need some level of write permission, whilst ordinary users may only be given read access. If the directory is publicly accessible read restrictions might be applied to sensitive information, e.g. any home telephone numbers should only be readable by internal users. Legislation relating to personal privacy issues may also restrict the amount information you can publish.

Assess the security policy in light of prevailing organizational procedure, perceived business needs and the needs of people who need the directory (both internal and external). What data is currently deemed sensitive? Will the introduction of the directory force re-evaluation of policy? It may be the case that the paper phone book is regarded as an internal document only. The business needs driving the introduction of a public directory might change this.

You should start by identifying classes of directory user, or access groups. The set of access groups that you come up with will be linked to directory management, functional and usability issues. For a simple publicly accessible directory the groups might be:

• Write permission to the entire database for system administrators.
• Write permission to some part of the database for data managers (if different from the above).
• Comprehensive read access for internal users.
• Limited read access for unauthenticated (external) users.

These access groups could easily be extended - more restricted write permission may be given to line managers, or even to individuals (staff may be permitted to write their own descriptions and Web page pointers for example), a set of external users may be regarded as trusted and given wider read permissions, and so on. There are advantages to keeping things simple. A complex security policy will require a lot of detailed design and implementation work. Further, the live system will demand a greater level of management effort and be less user-friendly.

7.1 Restricting Access Using Access Controls

Usage restrictions will generally be implemented through the use of directory based access controls (these are described in Section 2.2.7). Access controls are used to deny or grant permission to perform an operation on a specified piece of information. Controls can be applied to individual entries or to subtrees of entries. Figure 7.1 above illustrates the way in which access controls are applied. Here a top-level access control item (ACI) is applied prescriptively across a number of entries in the subtree. The control in the figure denies access to personal telephone numbers for all users external to the organization. A second access control, applied to the single entry for ?Joe Soap?, acts as an exception to this and makes the entries telephone number readable without restriction. The second access control takes precedence as it is more specific. This use of access control to implement exceptions should be avoided though as it is easy to get wrong. Such exceptions are also difficult to detect and change when overall changes are being made to the overall database.

The access control system defined in X.500 is very flexible. Many more combinations than shown in Figure 7.1 are possible. As a result it is tempting to design a highly functional system of access restriction. However, as stated, be careful not to allow the `weight' of functionality to swamp available management effort. When this happens errors can and will occur and the integrity of the security policy will be difficult to maintain.

7.2 Restricting Access Using a Filtering Proxy

Another way of restricting access to internal data is to place a filtering proxy on the organizational firewall. All external connections to the directory service would go via the proxy, which can be configured to prevent all restricted data from leaving the local area network. In effect such a service would `bounce' accesses to sensitive data, whilst allowing public data through the filter.

The advantage to this approach is that managers can be sure that the directory service will never communicate restricted data to service users outside the boundary of the local network. However, this also means that properly authenticated organizational users will not be able to access directory data if connecting from an external point.

7.3 Restricting Access Using Intranet and Extranet Services

Rather than providing limited access to a comprehensive enterprise directory, a simpler option may be to provide two separate directory services - one for internal use and for access by external users. The internal service would contain all information necessary for local use, and the external service tailored to provide access to the organization`s list of services, public contacts and other general information.