Mulesoft IPaaS – API Exposure – Security view

Access diagram – Security view

Key points

This is a hybrid model to deal with minimum access

1) Exposed API

a. This API is protected but further control is offered by simply not having any way to call APIs that could reveal bulk data or allow damage to many accounts

i. If the company should want to expose API for external developers to use this should point at non test data and still be monitored for hackers looking for access to more test data than they should have

1. Access to even test APIs should be controlled via accounts

2. This protection should be data activity protection not just API usage

ii. There should an ability to vertically and horizontally scale whilst being careful to control cost

1. Vertical scaling often means the work being requested is too intense but has a place where there is a high computational load and is simpler to manage

2. Horizontal scaling works well with smaller, less intensive payloads and works well with traffic spikes as often can be deployed quickly

iii. Reverse Proxy

1. Hides the actual IP of the service just as a router does not expose the internal network IPs to the consumer just the exposed IP

b. Internal API, these API have more access to data so there must still be controlled access.  Note: one study stated 14% of major breaches are due to internal bad actors

i. There should an admin user group with access to APIs that could cause a breach

1. Ideally such APIs should be a third group of API that only they can access

2) External API protection

a. F5 or similar, in AWS this will be a combination of the ELB group of balancers, should form the front door to internet access to API they provide

i. Load balancing

ii. Application acceleration

iii. DDos protection

iv. Bot Management

v. DNS security

1. Protocol inspection

2. DNSSEC validation

b. Access Control, authentication and authorization

i. Identification of the user will allow services to be made available

ii. Password policy relating to complexity and lifecycle should be in place

c. Public API Key

i. Each authorized user will be given an API key with all the normal protections that go with this

1. There should be a key rotation policy in place that is enforceable, so each key should have a lifecycle of usefulness

2. User activity and in-activity should be monitored and revoked according to policy

3. The throughput and bandwidth should be agreed and enforced

3) Internal API protection

a. Though there is no explicit F5, load balancing should be in place as needed to allow for failure and usage spikes