Database Reference
In-Depth Information
Here we mentioned only three internal services elements susceptible to attacks, but these
attacks are the most common and truly devastating. Common to these types of vulnerabil-
ities and attacks is that their target is static core service logic, encapsulated in component
or groups of components. However, this doesn't make them similar to the classic security
issues of the silo approach because we have the second native part of SOA—the service
interactions.
Services or components have to communicate with each other in order to carry out their
business tasks. What's worse for security personnel is that they have to perform it dynam-
ically, depending on numerous business conditions that involve a considerable amount of
external resources in an agnostic manner (see the CTU example, discussed in previous
chapters). We do not have strict domain security boundaries anymore because one mes-
sage can carry information about different (even business-opposing) parties. Different
parts of the message can be transformed or enriched separately by independent intermedi-
aries and so on. Information Confidentiality, Integrity, Non-Repudiation, and Origin are
constantly at risk when we have something in transit, and we constantly do. Thus, certain
measures (in the form of Patterns) shall be applied in order to protect the aforementioned
information properties. Luckily, these measures, covered by WS-* specs as Encryption,
Digital Signature, and Portable Trust, are quite mature and far older than the SOA concept
itself.
Before we go into the risk analysis, vulnerabilities, and SOA-related attacks, we would
like to jump ahead to some generic conclusions:
• It is not possible to have poorly designed services at the beginning (usually de-
signed as a PL/SQL Web Service or any web service by right-clicking in JDev)
and then convert them into something secure by hiding behind some magical "Se-
cure Gateway" or "Defense Perimeter". At best, the performance of such a ser-
vice, after applying all security restrictions, will degrade ten times or more
(Oracle estimates). This is because a Service Gateway (SG) will have to meticu-
lously screen every single call and validate every single response in order to
shield the holes in the service design and intentionally throttle the traffic, as the
service simply cannot keep up with the incoming requests. Surely, such a situ-
ation will feed the common stories about how the "naughty" security killed our
good performance.
• The logical outcome from the preceding point is that you as an architect should
ensure that the service design is safe and sound in every single detail and not just
by drawing blue boxes in PowerPoint and connecting them by red lines. As men-
tioned earlier, developing entirely in Java would probably be too much (although
Search WWH ::
Custom Search