WebSphere Application Server V6 Advanced Security Enhancement, part 2nd

This article is based on the security chapters of the IBM Websphere:deployment and Advanced Configuration book. This article has been significantly updated for WebSphere application Server V6 and has been edited to discuss security-enhancing aspects only. The text has been edited and typeset to be published as a separate article. Although this article is based on the WebSphere application Server V6, most of the problems here also apply to V5 and V5.1. One of the problems is peculiar to V6, which we will specifically point out. In addition, almost all other content is suitable for these three major versions, but screenshots and samples are from V6.

And then part 1th.

This article is the WebSphere application Server V6 Advanced Security Enhancement, part 1th: Security Enhancement Overview and a sequel to the methodology.

Advanced Considerations

Now, we will continue to discuss some advanced issues related to security enhancement. We will discuss the following:

Trust across calculated cells

Application isolation

Identity propagation

Limitations in WebSphere application Server security

In many cases, we will not make specific recommendations, but provide some important information to help you maintain and manage the security infrastructure.

Calculated cell trusts and quarantine

WebSphere Application Server Calculated cells should not cross trust boundaries. If you can't trust people completely, don't let them manage your cell or manage the computers in your cell. The WebSphere application Server management infrastructure uses a coarse-grained shared trust model within a range of calculated cells. Each application server includes it in the management infrastructure, including internal APIs. On the positive side, this eliminates the common point of control, making the application server highly independent and stable. However, it also has a negative impact on isolation. By using this method, the following content is implicitly included:

Each application server in the WebSphere Application Server computing unit has full administrative rights to the entire calculated cell. If any application server is compromised, all application servers will be corrupted.

Physical computer boundaries (stand-alone computers, LPARs, nodes, and so on) have almost no impact on cell security. The trust units in the calculated cells are all application servers on all nodes.

Process boundaries have little effect on the security of calculated cells. Placing an application in a stand-alone application server JVM is not much useful for enhancing the isolation of security angles within its computing cells.

Independent operating system identities have little impact on the security of calculated cells. Because the application server uses a variety of protocols to communicate with other parts of the computing unit, which are not managed by the operating system, the normal operating system projection works very well.

Each administrator has the same administrative rights for the entire calculated cell (within its assigned administrative role: administrator, configuration person, operator, or monitor).

This raises two key topics: management isolation and application isolation.

Manage Quarantine

For WebSphere application Server, all administrators have administrative rights over the entire calculated cell. It is not possible to allocate different permissions individually for different applications, different application servers, or different nodes.

If you are concerned about managing isolation, you can take immediate steps to address this need. First, you can take advantage of the different administrative roles in the WebSphere application Server.

Second, you can create custom administrative tools for the most common administrative operations (application updates, server restarts, and so on). You can limit the use of these common tools to administrators and applications. There are two possible ways to deal with this. The first method is to write custom wsadmin scripts and protect them with operating system permissions to ensure that each administrator can only run these scripts for the server to which they belong. The second approach is to write small Web applications that use j2ee™ security to authenticate administrators, and then allow administrators to perform specific restricted actions based on their access rights. The application itself can use the JMX API to manage calculated cells. Both of these approaches have been successfully applied by IBM customers.

Application isolation

Now we turn our attention to perhaps the hardest part of this article. Application isolation In this context is essentially about how to prevent the illegal operation of one application from causing damage to another application. This type of attack is difficult to avoid. The fact is that infrastructure software products, such as Java EE application servers, have not yet reached the level of sophistication of multi-user operating systems. They do not provide reliable isolation that is typically provided by the operating system across multiple users.