Xem mẫu
Planning and Building a Secure Web Services Architecture 389
O = ePortal.com
. . . ST = MA
STREET = . . . 44 Black Road
CN = . . . Mary Jones
Figure 12.6 ePortal customer LDAP schema.
On the security side, the type of schema used for our customers matches the format of the customer names in their X.509 SSL certificates, making this a seamless match as we move toward client certificates. In addition to the node names in the LDAP struc-ture, each node can hold a set of attributes, which are key/value pairs. (This is another example of an overloaded name. An LDAP attribute is not a security policy attribute, although a security policy attribute could be placed in an LDAP attribute value field.) LDAP attributes are where the telephone numbers and office numbers are stored.
Your security service could define a password attribute in the Common Name (CN) LDAPnode and use that attribute to store the user’s password, preferably in encrypted form. In order to store the password, the LDAP schema has to be expanded. The schema is controlled by an object class, which lists the required and allowed attributes; for example, the schema that we used for our customers is the Person Object Class. This object class requires the CN and the surname (SN). So, in addition to CN=Mary Smith, the security service has to have SN=Smith. But back to the password. The secu-rity provider could define a derived object class from the Person class and define an allowed attribute Password, or it could use a standard derived class that contains the password attribute. The reason that it may define its own object class is so it can define additional attributes, for example, a unique customer ID. In our case, we wanted our own schema in order to have the flexibility to add other marketing attributes.
If your security provider uses LDAP, there are a few things that you should look for in their LDAPimplementation. We have seen some instances in which the provider uses one of the standard fields for its own use—for example, putting the password in an attribute field that it guessed its customers would not use. Because you will probably be using the LDAP store for uses other than security, such as the other uses in ePortal, be careful, because you might have a need for this same field either now or in the future.
390 Chapter 12
A second thing to look out for is the type of connection between the security policy server and the LDAP server. LDAP supports SSL and simple password protection. If your security service does not use SSL and the LDAP server is distributed, that is, not on the same physical machine as the security service, then your security data is passed in the clear and is susceptible to snooping. The preferred security approach is to use a system that supports an SSL connection to the LDAP server. As usual, this should be looked at from a risk management point of view. What problems would you face if your security policy data was compromised? Be sure to check the type of connection from the service to the LDAP server that your security provider supports.
Not all your sensitive data will be handled by the LDAP server, even if that is your persistent store for your security policy data. In our analysis of our security system, we realize there is a distinction between policy data and functional data. Specifically, we transmit users’ credit card numbers as functional data, whereas our policy data includes information such as user passwords. In the eBusiness design, the credit card numbers are stored in the back-office tier in a relational database, and the connection to that database uses security service protection, including SSL protection. User pass-words are stored in encrypted form in the LDAP server and are passed as security pol-icy data. At eBusiness, our risk assessment is such that we cannot afford to have our security policy data, for example, user passwords, compromised. Therefore, we demand a security service that supports an SSL connection when passing policy data. An alternate solution would be to have the LDAPserver on the same physical machine as the security policy server and to isolate that machine. However, this limits the dis-tributed capabilities of LDAP.
Relational or Object Databases
Most LDAP implementations use a database beneath the LDAP APIs to store security data. Therefore, there is not a big difference in the persistent store for your security data whether your security service provider uses a database directly or through LDAP. The provider’s choice is reflected in the system-level effects, such as performance and fault tolerance. The provider’s choice of persistent store could also show up in other ways, such as additional costs if you have to pay for a third-party persistent store or the replication, distribution, and failover capabilities of the security system as a whole. There is one security aspect of the provider’s choice of persistent store that we dis-cussed in the previous section, which is how the transmission of the security policy data is protected. Just as with LDAP, the connection with the database chosen by your security provider must supply a secure channel to that database. This might be harder for the provider using an older database and thus might be skipped. However, it is crit-ical that you find out what protection scheme the provider is using for this connection
and make sure that it meets your security requirements.
The provider might be doing its own encryption of the data. If so, find out what encryption algorithms it is using and what type of key exchange it is using. The algo-rithms may be too weak and easy to break, or they may not be acceptable in the coun-tries in which you are or may be doing business. Another question to ask is: Can you change the algorithms and substitute new ones? In general, it is better if the provider uses a standard security connection rather than rolls its own, but the provider may have a good reason to use its own system.
Planning and Building a Secure Web Services Architecture 391
File Systems
Another way that the security service provider could store security policy data is by using the file system. This can be the least-secure method, depending on what addi-tional protection schemes the system is using. In many cases, the provider’s protection of the file system only relies on operating system protection—for example, setting the protection on a file to an operating system administrative owner.
There are two problems associated with a security service that relies on the security capabilities of the file system:
Attackers have studied operating systems’ security in depth and have discov-ered their weaknesses. Although these weaknesses are addressed as they become publicly known, operating systems are very complex beasts, and this complexity works against developing a secure operating system.
The programs that write to the file system store must have the permissions to access that store and are thus susceptible to compromise themselves.
Our general advice is to shy away from a security service that relies solely on oper-ating system protection for its persistent store, and look to solutions that combine operating system and cryptographic protection.
Securing UDDI and WSDL
Throughout this book, we have been concentrating on the security service itself with an implicit focus on securing the application. However, this is not the complete story. In any distributed system, including Web Services-based systems, there is an infra-structure of supporting services that are necessary to make the system work.
One of the most ubiquitous services is the directory used to find other services; in Web Services terminology, this is known as the Universal Description, Discovery and Integration (UDDI) registry. Your client application has to magically find a server that has implemented the service that you want to call. What if the UDDI returns to your client a WSDL file for a bogus service? How do you know whether you are really talk-ing to a legitimate UDDI registry and not a fraudulent one?
We regrettably have to say that implementations do not always secure these ser-vices. This can leave a big security hole in your system, which could very well be exploited by malicious attackers. So once again, we advise you to use the information that we provide and find out what infrastructure services are supplied by your appli-cation platform vendor or vendors and also find out whether and how they have secured them.
Security Gotchas at the System Architecture Level
In addition to paying attention to the way your security service provider implements and secures the underlying services, you should pay attention to the overall operation of the security service as a whole. The two main system areas that can be severely affected by the addition of security are scaling and performance. We’ll touch on each of these areas in the next two subsections.
392 Chapter 12
Scaling
The security solutions for distributed systems usually employ a security policy server to handle requests for authentication, authorization, and audit policies. Let’s take a look at what a security policy server is expected to do and why it can be a critical item in affecting the scaling capabilities of your system. There are two competing principles at work. On one hand, you want to be able to centrally administer your security data. On the other hand, funneling all the maintenance and requests through one server, especially for large, highly interactive companies like ePortal and eBusiness, can put an extreme load on that one server, to say nothing of the single point of failure that a lone security policy server would impose on the system. Another aspect is the geo-graphic distribution of the system in which you would want security policy servers distributed. The latter two requirements point to multiple security policy servers, whereas the first is most easily satisfied by a single security policy server.
One way for multiple security policy servers to act as a central point of administra-tion is for them to be stateless or to support very little state, which can be coordinated between the different security policy servers. A second requirement of multiple secu-rity policy servers is that maintenance be coordinated. For example, when our system administrator in London wants to update the same policy that our system administra-tor in New York wants to update, the security system should handle the multiple steps of a policy update from the two administrators as a separate, atomic update for each administrator. Because this could wind up in a last update wins situation, there needs to be notification of the updates between the distributed authorities.
The solutions to this class of problems are known, but they are not easy to imple-ment. Therefore, this is another area that you should look at closely; that is, how your security provider has implemented solutions to this scaling problem.
Another potential scaling problem for a heavily distributed system is key manage-ment, which is how the system stores and retrieves the cryptographic keys needed for encryption and integrity. There are commercial systems that your security provider can use such as those from RSA, Entrust, Verisign, and Baltimore Technologies.
Performance
When discussing performance, the phrase that comes to mind is, “There’s no free lunch.” In order to have effective security in a distributed system, work has to be done by the system, which means computing time. Once again, risk management comes into the picture. The tighter and finer-grained you want the security to be, the bigger the performance hit.
For the same level of security, there are a number of factors that can affect the per-formance of the security system. Some of these include:
Encryption algorithms Underlying transport Policy granularity Caching
As discussed in Chapter 3, there are two types of encryption: public key and secret key. Secret key encryption is much faster than public key encryption, but secret keys do
Planning and Building a Secure Web Services Architecture 393
not scale as well as public keys. In each of these encryption types, different algorithms have different performance characteristics. When encrypting large amounts of data, implementations usually exchange a secret key using a public key to protect the key exchange. The details of encryption are too arcane for most, so our suggestion is to look at the performance numbers for the systems under consideration and compare them with those of other systems.
The implementation of the underlying application platform transport is another mechanism that can seriously affect performance because the security system itself is distributed and uses the transport to do its work and get the data it needs.
The more finely grained the policy, the more work the security system must do and thus the slower the performance. This is a trade-off that you can use when designing your overall security system. For example, in some cases performing authorization at the application level is appropriate, whereas in other cases authorization at the inter-face or even method is required for adequate security.
Caching can boost performance by orders of magnitude if it is well integrated into a security service. For example, an access decision could entail multiple trips to the secu-rity policy server and from there to the persistent store for each piece of data. This offers multiple opportunities for caching the data to improve performance. However, caching can cause a security problem if not done properly. For example, if a break-in is discovered, you will want to flush the cache or that party or parties will continue to have access until the cache times out. If your provider has not implemented an emer-gency cache flush, you will have to bring your whole system down to remove the cached values. Another problem with a badly designed caching system is the lack of control over the timing of updates to the security data values. Has your provider given you the ability to control the updates to the cache?
In the end, what you, the user of a security service, are concerned with is the overall performance in your environment. It’s the job of the security provider to balance the performance of the system against the functionality of the security. It’s your job to assess the overall performance of the system. However, the security and system trade-offs in the various parts of the system make the subject of performance highly complex. There-fore, be sure that the performance characteristics that you examine match the type of work that your system will be asked to do. A performance number that measures the performance of calling the same method 100,000 times is not very useful if your system does separate method calls to a large number of methods with very little repetition.
Finally, it is best to get performance numbers from a third party. However, these are hard to get, so you will probably have to do your own comparative performance tests. There is a need for companies that perform independent security performance tests of distributed application server environments, and we expect to see them entering the industry market soon.
Summary
In this chapter, we first took a step back from our detailed analysis to look at how to define a Web Services security architecture. We began by discussing the challenges of Web Services security. We talked about issues such as interacting securely across sys-tem boundaries, trustworthiness, and security evolution. We then provided some EASI
...
- tailieumienphi.vn
nguon tai.lieu . vn