In this article, I am going to explain in high level how MuleSoft Anypoint Platform with different level of security shields are protecting the backend services through API wrapper created in this platform.
From the below context diagram, the backend services are protected by Mule platform in a different invocation of mule API to back-end service. Let’s have a detailed look at each phase of API invocation.
Let’s say API consumer/partner, who wanted to access “Company X’s” asset through the microservices created and hosted in the company DMZ network. The below table describes each step of API invocation in details.
|1||By default Mule, Anypoint platform is hosted in AWS regions across global. For data sovereignty purpose, customer can choose the specific region such as AU data should reside with Australia. Though only metadata stored US-east and EU specific to EU region, all other sensitive data is stored within a specific region for Regulation perspective.
So first of security shield is provided by AWS, which gives not only high availability 99.999 also project resource access by using ASW Shield. Mule support External Vulnerability Scan from approved Scanning Vendor for Penetration testing, open up firewall request to do penetration testing can be achieved by sending the email to firstname.lastname@example.org. This AWS shield protects the Denial of Service (DDoS) attacks in the first layer.
|2||In addition to Mule OAuth 2.0 Provider, MuleSoft offers out-of-the-box integration with PingFederate, OpenAM and Open ID Connect OAuth 2.0 Providers. That means, Mulesoft can integrate with external IdP like Azure AD, Ping Identity to manage entire user store, Authentication and Authorization by external IdP.
2factor Auth or Biometric authentication layer can be added on top external IdP based organisation’s requirement. Using standard SAML 2.0, OAuth and OpenID, Mule Anypoint platform can be seamlessly integrated with external Identify.
In some of the cases, seen Azure AD is used as external IdP. Refer my post on Mule integration with Azure Active Directory
|3||Application owner of applications created in MuleSoft Anypoint platform can enforce CliendID enforcement to the application(s), which means the client application must be registered in Anypoint platform and should have ClientID and Client Secret at least to consume the API.
As an organisation admin or owner has privileges to approve/revoke client application registration through API Manager
|3a||ClouldHub is hosted in AWS and Mule runtime can be deployed within VPC ( Virtual Private Cloud) to make more secured manner. By creating the VPC for mule run time, you have IP allocated boundary for them. Each VPC can have multiple Mule environment, usually, there will be at least two VPC for Prod and non-prod environments.|
|4||Another security layer is dedicated Load-balancer, which will control the work to workers request in the environment in VPC. DLBs are optional in the deployment. Advantages of having DLBs are SSL configuration to custom certificates and optionally enforce two-way SSL client auth. Also, you can have a proxy rule to map the custom domain rather than using cloudHub.io domain created by Anypoint platform. An additional license will be applied for DLB setup.|
|5||Mulesoft provides out-of-box OAUTH2.0 provider through which you can secure API’s created by mandating ClientID and ClientSecreat with an access_token. Similarly, it supports external Identify management integration such as Okta and Pingfederate, Also support dynamic client registration can be accomplished by configuring client Identity management with an external Identity Provider.|
|6||As the next level of security, the Mule API can be more secured using out-of-box policies applied. Refer some of Security Policies section for further details. These policies are applied around API.|
|7||Within API flow, another level of securities such as Digital Signature, Encryptions, Threat Protection and SQL injection etc.. Refer Message security section and Transport security section below in the table.|
Also, Mule Anypoint platform provides a set of granular policies from out of the box, which can be injected and enforced to outbound and inbound API’s to cater to compliance, security and Quality of Service. Developers can also create their own custom policies to cater to specific business requirements
Mule can encrypt an entire payload or several fields of data within a message. A developer can encrypt message content to prevent unauthorized access. Typically data need to be encrypted are such as a password, credit card number or social security number (SSN).
Different types of Encryption Strategies:
Mule Credentials Vault:
Mule can encrypt properties in a properties file. The properties file in Mule stores data as key-value pairs. Mule flows may access this data — usernames, first and last names, credit card information — as the flow processes messages.
In most of the cases, this file needs to be encrypted in the context of Anypoint Enterprise Security, Mule refers to the encrypted properties file as the Mule Credentials Vault.
Throttling -SLA-Based The number of messages per time-period processed by an API is throttled at a maximum value specified in the SLA tier. Any messages beyond the maximum are queued for later processing. Enforcement is based on the client ID passed in the request.
Throttling The number of messages processed by an API per time-period is throttled at a maximum value specified in the policy. The throttling is applied to all API calls, regardless of the source. Any messages beyond the maximum are queued for later processing.
XML / JSON Threat Protection
Malicious attacks on XML applications typically involve large, recursive payloads, XPath/XSLT or SQL injections, and CData.
JSON Threat Protection Applying the JSON threat protection policy can limit the size of JSON payload and thwart recursive additions to the JSON hierarchy
IP Blacklist API calls from a defined set of IP addresses are denied.
IP Whitelist All API calls are limited to a defined set of IP addresses.
Rate Limiting – SLA-Based The number of messages per time-period processed by an API is rate limited at a maximum value specified in the SLA tier. Any messages beyond the maximum are rejected. Enforcement is based on the client ID passed in the request.
Rate Limiting The number of messages processed by an API per time-period is rate limited at a maximum value specified in the policy. The rate-limiting is applied to all API calls, regardless of the source. Any messages beyond the maximum are rejected.
|Anypoint Platform Security Compliance
|Transport Layer Security
Data in Transit MuleSoft understands that data is vulnerable while in transit. MuleSoft provides several options for data in transit: