4

Let's assume a service-oriented architecture (SOA) with hundreds of services. The services are completely isolated – what is behind their APIs is an implementation detail.

Different services can have different security policies – i.e. who can access the service. For example, a service can be fully public, accessible to a subset of employees, accessible to a subset of other services, etc. Some services may even have that specified on the API level, for example a public service with some internal API calls (is that a bad idea?).

How should the infrastructure interconnecting the services reflect the security policies? Are there any standard approaches to this? Is it known how Amazon does it - they surely must have an automated solution?

I googled a bit but didn't find any good resources on this. Links are absolutely ok as answers to this question :)

fhucho
  • 245
  • 3
  • 10
  • Our company is currently using ZeroMQ and I think it may be of help. – Mardwan Apr 22 '14 at 08:38
  • I don't know the answer but with a little search I found this presentation. I think you can find more useful information by using right keywords. http://www.iaria.org/conferences2007/filesICCGI07/Tutorial_SecurityPatterns.pdf – ibrahim Apr 19 '14 at 14:29

2 Answers2

1

Well.. that's quite a broad question, but, let me see what I can uncover for you. Let's start with your questions:

  1. Some services may even have that specified on the API level, for example a public service with some internal API calls (is that a bad idea?).

I'm not sure I understand what is being asked here. When you say "internal API call", I am assuming that you are referring to a private service that the public API is accessing. This is indeed "ok", assuming that the internal service is behind a strict firewall.

  1. How should the infrastructure interconnecting the services reflect the security policies? Are there any standard approaches to this?

Let's start with the creation of a new service. I highly recommend viewing this book, especially for access controls. Essentially, a newly created service or subject should assume the following:

  • A secure default policy should be applied to any newly created subject
  • The attributes of the system should not be expressed in terms that can easily be forged such as an IP address.
  • A user ID or service ID should remain permanently assigned to a service/subject

Once created, the service will then need to communicate with your internal services. In terms of security and policy, this is rather difficult to answer since it depends on what you choose for transfer protocols / messaging / etc... For example, using an internal architecture such as ESB. Here are a few articles to outline utilizing ESB:

and a few security focused articles outlining SOA ESB:

However, I do know that amazon does not use ESB via this article, though I did find a few articles that may help as well:

Again, the security policies will reflect what the transfer protocol / messaging protocol, etc for service to service. For example, services communicating via proprietary ports (all behind a firewall).

Hope something in there can help!

dperconti
  • 241
  • 1
  • 6
1

Amazon and others use "Universal Description, Discovery and Integration" (UDDI) which has it's own standard. Companies come together under the OASIS group to tackle standards with regards to SOA, UDDI, WSDL, SOAP, etc. There are many companies that address software to pull that off however, there are standards. I'd begin here for an index, then here, followed by a variation of searches for anything more specific (e.g.: UDDI, SOA, WSDL site:aws.amazon.com or whatever other provider). Also noteworthy: "An End-to-End Security Auditing Approach for Service Oriented Architectures"

munkeyoto
  • 8,702
  • 17
  • 31