Further Reading
| Understanding and Deploying LDAP Directory Services > 11. Privacy and Security Design > Analyzing Your Security and Privacy Needs |
Analyzing Your Security and Privacy NeedsNow that you have an idea of the kinds of threats your directory may face and the tools at your disposal to protect against them, it's time to turn our attention to analyzing your environment to determine your specific needs. It's important to tailor your security design to your environment and the needs of your users. Failure to address security needs can compromise your entire service and make an otherwise successful deployment fail. On the other hand, if you design a system that imposes needless and cumbersome security constraints on your users, the service can easily become unpopular, go unused, and fail. The key to finding the right balance is to understand your other directory design requirements and how they affect your security design, and the security needs of your environment and your users. Directory RequirementsMany aspects of the directory design we've discussed to this point have an impact on security, and vice versa. Some of the more important design decisions that have an impact on security are covered in the following sections. Read or WriteIf your directory is write-only, it may require more security than if you do not allow users or applications to update the directory. Directory write operations are often held to a higher standard of authentication than directory read operations. For example, you might decide that simple password-based authentication is sufficient to read information from the directory, but to update that same information, a client must authenticate using a public key certificate over a protected SSL connection. With this setup, you can be confident about the integrity of the data in your directory and changes to that data received from clients . You can be less confident that only authorized users are accessing the directory, but you can still maintain some level of assurance. Sensitivity of DataUnderstanding the type and sensitivity of data in your directory is one of the most critical aspects affecting security. The data in your directory is what your security design is there to protect. If your directory contains publicly readable information, there may be no need for access control. You still may need to be concerned about the integrity of the information, however. If there are different sensitivity classes of data in your directory, you need to consider how best to protect each one. For example, you may consider name data to be public data and therefore require minimal protection. On the other hand, if your directory contains Social Security numbers or salary information, a much greater level of protection is called for. A useful design exercise is to list all the attributes that will be held in your directory and to try to categorize them based on their sensitivity and the type of access and protection required for each one. Table 11.1 shows an example of this kind of categorization. Table 11.1. Examples of attributes and sensitivity classes
After you choose your directory software, you can use this table to help design your directory access control. ReplicationIf your directory is replicated, you need to be concerned about the security of the data as it is replicated. It's not much good to protect the data if you pass it among servers without similar protection. Also, if your replication architecture calls for copying data outside your own domain of control (e.g., onto every LAN), a lot of replicas will exist, not all of which will necessarily be held to the same stringent security requirements you place on your own machines. In other words, it's not much good to use directory access control to protect entries if they are going to be replicated to machines controlled by some of the very people you are protecting the entries against! Think about the network links between replicas. If they are secure, or at least free from access by users, it may be acceptable to pass directory replication updates in the clear. On the other hand, if replication updates must traverse networks accessible to users who may be potential security threats, you'll probably want to protect replication exchanges from eavesdropping, tampering, and other security threats. Replicating over connections secured by SSL might be a good choice in this situation. Make a graph representing the replicas you plan to create and indicate the security level of each network link involved. Then label each replica with its physical and administrative security levels. An example of such a graph is shown in Figure 11.2. Figure 11.2 Replication and network topology. Think about the physical and administrative environments in which the replicas of your directory will live. Are these environments under your control? Are they up to the same security standards to which you hold the replicas you operate ? If not, you should reconsider your replication policy. In Figure 11.2, replication updates between the master and first-level replicas may not need protection from eavesdropping because they occur over a network inaccessible to users. The network is also hard to tap because of the optical technology it uses. However, replication updates between the first- and second-level replicas probably do need protection because they occur over user-accessible networks. AdministrationIf your directory administrative model calls for delegation, you must be concerned with the privilege level granted to subordinate administrators and their ability to increase their own privilege level. You also need to be concerned with other aspects of the administrative environment of your directory. Recognize that you will likely need administrators of the service itself who are different than the administrators of the content held by the service. Service administrators start and stop the service and make sure it runs smoothly, is configured correctly, and is replicated properly. Typically, this function is performed by an experienced system administrator. Content administrators are responsible for day-to-day administration of directory content, adding and deleting users, resetting passwords, and similar tasks . Typically, this function is performed by data processing staff, administrative assistants, and sometimes users themselves . The two types of administration require different kinds of security considerations. Understanding Your EnvironmentAnalyzing your environment is another important prerequisite to understanding your security requirements. If you understand your environment, you will have a good idea of the kinds of threats your directory will face. Based on these threats and the other information you collected previously, you'll be able to choose appropriate safeguards for your directory. At a minimum, you should consider the user community, directory accessibility, network environment, and physical security. The User CommunityThink about the community of users that will be using your directory. Are they company employees who have employment contracts and other incentives not to misbehave and create directory mischief? Or are they students with far too much time and cleverness on their hands? Obviously, different user communities require different security measures. The employee community may require relatively little security on the directory, other than that required to prevent accidental misuse of the service. It's hard to foolproof your directory from this kind of unintended abuse. Using access control and minimal authentication is a good way to guard against this kind of problem. Beware of trusting your employee community too much, however. As we mentioned previously, security problems often turn out to be inside jobs. The student community may well require more robust protection mechanisms. A user communities;security>determined and clever attacker is difficult to stop. Access control and strong authentication mechanisms provide a good start, but you may want to require SSL access to the directory, do extensive auditing, and institute physical security procedures around your directory servers as well. Directory AccessibilityThink about how widely accessible your directory is. Is it behind a firewall, or is it availab le over the Internet? In the firewall case, the community of users that can access your directory is probably restricted to people in which you have some level of trust, however small. You can probably get by with more limited protections in this situation. Perhaps a good auditing system is enough ”on the theory that anyone inside the firewall has an employment contract or case, the other incentive to be good, and all you need to know is who has been bad. In the Internet case, your directory is available for the world to access. Even if no information in your directory is accessible to users who have not authenticated, there is still a significantly increased risk of exposure to security problems. Attackers have free reign to probe your directory for weaknesses, your directory is more vulnerable to denial-of-service attacks, and any security holes in your directory can be more easily exploited. In this situation, your decision about how much security is required depends more on the consequences of a security breach and the attractiveness of your data and organization as a point of attack. If your organization is prominent ( especially among the computer-literate), you can count on being a more likely candidate for attack by the mischievous or malicious. Typically, attacks of this kind are motivated by a desire for notoriety (or sometimes revenge , in the case of a disgruntled ex-employee, for example). There is little chance that a security breach will go unnoticed; one of the goals of the attacker is to make his or her breach of your security known. If the data held in your directory is especially valuable , you can count on being a prime candidate for attack. This kind of attack motive can be more problematic because it is often in the attacker's best interest to conceal the fact that any security breach has taken place. Indeed, an attacker in search of credit card numbers, competitive analysis information, or other time-sensitive information may find the information they steal worthless if the fact it has been stolen is revealed. The Network EnvironmentOne of the most vulnerable points in your directory service can be the network over which clients access the directory and directory servers communicate with each other to pass replication updates or perform other server-to-server communication. You need to understand these vulnerabilities and the security implications they generate. Create or obtain a map of your network's topology, such as the one shown in Figure 11.2. Make sure you understand all the paths between your servers and between servers and clients. If these paths are susceptible to eavesdropping by unauthorized entities, you must find another way to protect directory data as it travels on the network. Such a vulnerable configuration that needs protection is a network in which your server and client machines all share a broadband, nonswitched Ethernet. Any client on this network can easily listen in on traffic not intended for it. A good option might be to require SSL for client/server and server/server communication. This way, eavesdropping does an attacker no good because the traffic is encrypted. If these paths are not susceptible or at least not wide open to access, SSL may not be required. An example of this situation might be a configuration where your server network is physically secure. Perhaps a fiber optic link (difficult to tap) connects your server network with your user networks, and your user networks consist of switched Ethernet hubs connecting user machines. In this environment it is much more difficult to eavesdrop on traffic not intended for you. You must generally compromise a router or other machine on the network to accomplish this, but it is not impossible to do. Taking these precautions raises the bar for your attackers. Physical SecurityThe physical security of your servers is important. As we pointed out previously, securing your network and administrative procedures does not necessarily do you a lot of good if the physical security of your directory server machines is not protected. There are a number of steps you can take to ensure a high level of security. Make sure your server is kept in a room accessible only to authorized users. In high-security environments, you may want to employ cryptographic smart cards or biometric security procedures to permit entry to the room and use of the server. A retinal scanner is an example of a biometric security device. Understanding Your UsersA factor often overlooked in security design is the needs of your user community. Understanding how your users will use the directory and view the data it contains, and what their security expectations are, will go a long way toward helping you design a security infrastructure that will make them happy. This, in turn, will go a long way toward making your directory service successful and yourself happy. How your directory will be used, both by users and applications, can have a significant effect on the security needed by your directory. For example, a directory used for phone book searches and other noncritical tasks certainly has lower security requirements than a directory used to route mission-critical email or perform other important functions. How your users view the data in your directory is also a relevant factor. A directory that contains personal, but not secret, information about users may not need high security from your point of view, but your users may feel differently. You should be sensitive to these needs. Your users may have a sense of ownership about the data in the directory and strong feelings about how it should be protected from unauthorized access and certainly from unauthorized tampering. They may also feel differently about specific attributes such as home addresses and phone numbers. Be prepared to defend your security policy for each attribute in your directory, or be prepared to have a flexible policy that can be changed by request on a per-user basis. Designing a flexible access control policy can be helpful. For example, suppose your directory is accessible both inside and outside your organization and contains both home and work address and phone information. The possible access combinations for these sets of information, for clients inside and outside your organization, is given in Table 11.2. If you were to poll your user community, you would likely find out that there are plenty of users who want each combination. Table 11.2. Possible access combinations for home and work information inside and outside an organization
Some of these combinations may appear strange to you, but chances are that each one is desired by one or more of your users. It may seem unusual to want home information accessible to outsiders but not to your fellow employees. But one reason for this might be that publishing a home telephone number to colleagues could encourage them to call you at home ”which you might want to discourage; however, you might want friends across the world to have access to your home phone number. How do you provide a flexible access control system that allows your users to choose the model most appropriate for their needs, yet without undue administrative burden for either them or you? Although there is no one answer to this question, it is important to understand the capabilities of your software's access control features and how they deal with situations like this.
|
Index terms contained in this sectionaccessibilitysecurity issues 2nd 3rd administration directory security issues 2nd communities user director y security directory security security needs 2nd 3rd 4th 5th data sensitivity directory security issues 2nd design security 2nd directory status requirements 2nd 3rd 4th 5th 6th 7th environments 2nd 3rd 4th 5th 6th 7th user needs 2nd 3rd 4th 5th directories security 2nd 3rd 4th 5th 6th 7th 8th 9th administrataion 2nd data sensitivity 2nd environments 2nd 3rd 4th 5th 6th 7th read/write status 2nd replication 2nd 3rd 4th user needs 2nd 3rd 4th 5th employee user communities security environments directory security 2nd 3rd 4th 5th 6th 7th accessibility 2nd 3rd networks 2nd 3rd 4th physical security 2nd user communities firewalls maps network security needs security 2nd directory status requirements 2nd 3rd 4th 5th 6th 7th environments 2nd 3rd 4th 5th 6th 7th users 2nd 3rd 4th 5th networks security issues 2nd 3rd topologies physical security environments 2nd read-only directories security issues 2nd replication directory security issues 2nd 3rd 4th security firewalls needs 2nd directory status requirements 2nd 3rd 4th 5th 6th 7th environments 2nd 3rd 4th 5th 6th 7th users 2nd 3rd 4th 5th sensitivity data directory security issues 2nd status directory security 2nd 3rd 4th 5th 6th 7th administration 2nd data sensitivity 2nd read/write status 2nd replication 2nd 3rd 4th student environments directory security user communities topologies network security users directory security 2nd needs directory security 2nd 3rd 4th 5th write-only directories security issues 2nd |
| 2002, O'Reilly & Associates, Inc. |
EAN: 2147483647
Pages: 245