Securing an SOA is a complicated business. It isn't a single concept but
various moving parts such as: encryption, authentication, and
non-repudiation. Not only is there no "one size fits all", but this
multi-dimensional nature means there isn’t even a single sliding scale
for low, medium and high security. One service might need transport
encryption (e.g. SSL) and non-repudiation but have no need for
encryption at rest behind the firewall; another requires encryption
end-to-end including at rest, but not need non-repudiation - neither is
more secure, merely differently secure. In an SOA some security
requirements will be enterprise wide (e.g. perimeter security), whilst
others will vary on a service by service basis (e.g.
authentication/encryption levels). This quickly becomes a complex
picture.
Aside from the wasted expense, applying unnecessary security can reduce flexibility, increase complexity, and deny the benefits of the cloud. Obviously business requirements come first (it's why we're here after all), and tight budgets mean security needs to be targeted to where it's really needed. In this security vs flexibility consideration, one final aspect is worth considering: how does security affect SOA benefits? There's one obvious example, message level encryption can reduce the ability of intermediaries to validate messages, so the ESB or XML firewall can't stop invalid messages. Here a security option can directly impact a non-security aspect of the solution.
It's obvious that defining SOA security is complicated to say the least. This was a challenge we had whilst discussing security requirements recently. The solution we found was a radar graph showing options which looked a bit like this:
Looking at the graph:
In a future post I'll discuss the impact of the various options on each axis in terms of cost, flexibility and any other knock on effects.
Aside from the wasted expense, applying unnecessary security can reduce flexibility, increase complexity, and deny the benefits of the cloud. Obviously business requirements come first (it's why we're here after all), and tight budgets mean security needs to be targeted to where it's really needed. In this security vs flexibility consideration, one final aspect is worth considering: how does security affect SOA benefits? There's one obvious example, message level encryption can reduce the ability of intermediaries to validate messages, so the ESB or XML firewall can't stop invalid messages. Here a security option can directly impact a non-security aspect of the solution.
It's obvious that defining SOA security is complicated to say the least. This was a challenge we had whilst discussing security requirements recently. The solution we found was a radar graph showing options which looked a bit like this:
Looking at the graph:
- The three axes above the horizontal (Network filtering, Network separation, Security location) will usually be determined for the architecture as a whole.
- The two horizontal axes (policy separation, data at rest) could be decided on a service by service basis but will likely have wider impacts if security is increased (i.e. introducing central policy management will require new products, masking audit logs will potentially impact all services if a common logger is used.
- The three axes below the horizontal can be determined on a service by service basis and as such can be included in the service NFR template.
In a future post I'll discuss the impact of the various options on each axis in terms of cost, flexibility and any other knock on effects.
No comments:
Post a Comment