API Oriented Architecture Security The development of SOA in an API oriented world. Security Swisscom (Schweiz) AG

Transcription

1 API Oriented Architecture Security The development of SOA in an API oriented world. Security Swisscom (Schweiz) AG

2 SOA Primer. Where API Oriented Architecture Comes from. Standard SOA thinking: SOA is designed to enable Internal systems/services within an organisation flexibility in making their respective information available for use within an organisation. Flexible protocol choice for integration (Different XML schemas, Adaptors for protocols such as MQ Series, SOAP, etc.)

3 SOA Primer. Some known limitations Flexibility Data A As *Trusted more is «Available» services in environment* protocol are added choice the assumption Middleware and means B2B compromises connectivity SOA made Platform. grows traditional are made Data complexity ownership with SOA if security is you becomes often have not ( hard access Role defined/known Concepts/Plaintext to to manage. the bus, it or is cared assumed protocols about. that etc.) you are a trusted user.

4 API s: The Secret to Amazon s Success. Jeff Bezos s 2002 mandate. All teams will henceforth expose their data and functionality through service interfaces. Teams must communicate with each other through these interfaces. There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another team s data store, no sharedmemory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network. It doesn t matter what technology they use. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. Anyone who doesn t do this will be fired. Thank you; have a nice day!

5 Pro s of an API Oriented Architecture: Data Replication - The security Nightmare. It Starts Simply. A CRM System is setup to handle customer data. Names, Addresses, contact data, product information etc. Others get in on the action and before you know it Then you realise you have you need multiple the data systems for billing you need as to protect. well. So you Instead copy the of potentially data to your just billing one. system. -Name -Address -Product Info. Then marketing realises they need the info for their new campaign system. They get this data from billing not knowing that the source was actually the original CRM system.

6 The Solution: SOA, Simplified through API s. You Start with creating An API Gateway, In essence a middleware standardized usually with REST/JSON API s. You then ensure that your Data Masters (In this case the previous CRM system) publish an API making their information available for use by others. When Others need the data, they request an API key to the published API from the data owner, and they can simply access it, ensuring the data is always up to date. -Name -Address -Product Info. With From this a Business we resolve perspective: four potential vulnerabilities from a security perspective: We Minimize the number of systems storing data. (Less to protect) We speed up project development. (data is easily available upon request) We ensure that access control resides with those who are responsible for the data. We We increase reduce costs. the integrity (less data of data. replication less storage costs) We W Ensure reduce secure rework. protocols (data integrity are used is more for communications. easily maintained)

7 Taking it to the next level: External Integration. Now it gets tricky. What data do you make available publicly? A Clear classification of data is required. Data Owners need education/awareness in this area. Fit for Use: What services can you use for what purposes? Salesforce is quick and easy to use for sales leads, Amazon storage is cheap.but fall under US Law and often provide no service level. API Mashups. Data is often innocuous on it s own but how could it be leveraged when mixed with other published data and made available to 3rd parties. ecure_mashups_by_deryck.pdf

8 Taking it to the next level: External Integration. Border gateway Management. API Gateway s are NOT border Gateways. They are designed to offer maximul functionality not Maximum Security. Get it wrong and your most private API s may not be so private.

9 Taking it to the next level: External Integration. Border gateway Management. Web Application Firewall. Traditional Firewalls only work at the Network Layer (Layer 3) or Transport Layer (Layer 4). API s are operating at the Application layer (Layer 7). This means firewalls only provide an extremely limited defense. We need a Web Application Firewall.

10 Conclusion: API Oriented Architecture Security & Business working together. Business Goals: In the end Business goals drive Security goals. Not the other way around. In this instance we have the possibility for synergies between the two. Increasing time to market Reducing costs AND increasing security of services offered Security Points: Ensure a good basis service architecture. Evaluate each API being published seperately. Evaluate the target «audience» for the API. Consider mashups and their implications.