However, SOA has affected security concerns in a number of other ways too. Of course, it raises exactly the concerns just discussed – that is, by opening up applications to be callable as SOA services, perhaps as web services for example, there is the danger they might be called by client applications without the requisite authority. While this is an issue that must be resolved, this type of security problem is fairly well understood. Companies are used to protecting access from the network, authenticating users and operating access control lists. Assuming the SOA infrastructure being used has the right level of security granularity implemented, this should make it possible to control access effectively. Similarly, ensuring privacy of data in transit across networks is a familiar problem, and there are numerous encryption standards that can be deployed to achieve the necessary level of protection.
But SOA brings new challenges, and frankly the market is not dealing too well with the whole SOA security issue. Just look at some of the draft web services ‘standards’ associated with security: WS-Security, WS-SecureConversation, WS-SecurityPolicy, WS-Trust, WS-Federation and many more. Now people understand that most web services standards are immature, ill though-out and not really of much use, but it is interesting that WS-Security at least is pretty mature now, reinforcing the fact that security is a big concern in web service usage and SOA in general.
Perhaps the most interesting security implication of SOA, though, is the danger of compromising existing security domains. The problem stems from the fact that the whole principle of SOA is to move from a monolithic application base to a collection of shared services representing individual business operations. So, for example, instead of every application having a ‘Create Customer’ routine, a single ‘Create Customer’ service is provided that can be called by all applications as needed. Of course, this has many benefits, which is one of the reasons SOA is so popular today. Application maintenance costs are reduced, systems become more agile and flexible, and service quality improves. But from a security viewpoint, turning a business application into a collection of SOA services that may be operating anywhere across the SOA deployment has more worrying implications.
Consider a key business application which has stringent security requirements associated with it. Providing the required level of security could involve means such as hardware-based encryption, physical access controls and sophisticated intruder detection systems. But the security domain in this case is built around the application itself. This is a natural approach when the application is monolithic in nature, and is running on a specific machine at a known location. In this scenario it is relatively easy to exert a strong level of security control – almost like managing the security of a landlocked country with closed borders. Now consider the effects of implementing an SOA strategy, where this business application is broken up into some specialised code and a selection of calls to shared SOA services such as the ‘Create Customer’ example. With SOA, the principle is that the caller of a service does not need to know where the service is running, or on what technology.
But this flexibility shoots holes all through the existing security domain. As soon as other systems are involved as part of executing the business application, there is a risk that the previous level of security will be compromised. For a start, if access controls to the ‘Create Customer’ service are not stringent enough, then there is a greater risk that the service might be modified incorrectly, either unintentionally or maliciously, resulting in damage to the service level of the key business application. If the ‘Create Customer’ service is running on a machine without the same encryption policies, then sensitive information might be accidentally exposed.
Perhaps the most worrying part of the problem is that these changes could happen without the implications being understood. The worst security problems are the ones that staff do not know are there. The answer is all tied up with the much-vexed question of SOA governance and management. Procedures must be put in place to carefully consider the implications of sharing a particular SOA service. Policy management tools combined with a strong design-time registry should make it possible to avoid accidentally using a service which does not have the appropriate security specifications. But in the end, controlling this security problem effectively comes back to the secret of sustainable SOA success – plan carefully, and don’t ignore working practices and management procedures when bringing in and deploying your SOA strategy.
Steve Craggs is Founder of Lustratus.
Comments