Best Practices for API Security
Download as PPTX, PDF20 likes10,583 views
The document discusses best practices for API security using MuleSoft's Anypoint Platform, emphasizing the importance of safeguarding APIs against potential breaches, highlighted by significant financial losses from compromised records. It covers identity management, authentication, authorization, integrity, confidentiality, and availability as key security concerns, while presenting various capabilities of the Anypoint Platform to ensure secure API management. The conclusion reinforces the necessity of APIs for business agility and the platform's effectiveness in providing robust security measures suitable for high-stakes industries.
Best Practices for API Security
- 1. Nial Darbey, Senior Solutions Consultant, MuleSoft Aaron Landgraf, Senior Product Marketing Manager, MuleSoft January, 2016 Best Practices for API Security: Anypoint Platform Solutions
- 2. Why API security is so crucial “The estimated financial loss from 700 million compromised records was $400 million, which shows the real importance of managing data breach risks .” • -Verizon 2015 Data Breach Investigations Report
- 3. All contents © MuleSoft Inc. Introduction 3 • In this presentation we will show how MuleSoft’s Anypoint Platform can ensure that your API is highly available to respond to clients and can guarantee the integrity and confidentiality of the information it processes. • We will explore in depth the main security concerns around APIs and look at how the IT industry has responded to those concerns. • We will also present Anypoint Platform as fully capable of managing and hosting APIs that are secure according to the highest industry standards.
- 4. All contents © MuleSoft Inc. Table of Contents 4 1. Identity 2. Main Security Concerns 3. Mule Runtime Security Capabilities 4. Anypoint Platform Security Capabilities 5. Summary Scenario
- 5. Identity
- 6. All contents © MuleSoft Inc. Identity 6 • Identify Users, Apps and Servers • Record of Identities • LDAP Active Directory • Identity Provider Identity is core to the world of security. You must be able to recognize the Apps that consume your API, the Users of the same and the Servers that your API calls out to. Likewise, your API should be able to identify itself to both Apps and Servers. Likewise, your API should be able to identify itself to both Apps and Servers. You need an Identity Store to which you can refer to verify your recognition of Apps and Users. The Identity Store could be a database, but an LDAP server is the most popular solution. Active Directory is a popular LDAP implementation. An Identity Provider is software which is dedicated to managing the interaction with the Identity Store(s) for authentication and authorization purposes. Your API can function in this role though it is much more preferable to delegate this responsibility to the Identity Provider.
- 7. All contents © MuleSoft Inc. Identity > Authentication 7 • Client and Server • Username / Password Credentials • Multi-factor Authentication • Token Based Credentials When you are presented with an App ID or a User’s username (claim) in a call to your API, you must be able to verify the authenticity of the claim. This is done with some form of a shared secret. When your API acts as Identity Provider, it typically authenticates the claim by passing the same credentials to the LDAP server. The use of username / password pairs as credentials is a very common practice but it is not recommended from two perspectives: Passwords have a level of predictability whereas the ideal is to maximize on randomness or entropy. Also, the maintenance of passwords is difficult. If you need to change a password then you immediately affect all Apps that make use of that password. Recognizing the weakness of username and password credentials, an App using Multi-factor Authentication (MFA) demands from the User a one-time usage token she receives after authenticating with her credentials. Token based credentials are a better alternative to Username Password Credentials, which provide higher entropy and a more secure form of authentication and authorization.
- 8. All contents © MuleSoft Inc. Identity > Authorization 8 • Role Based Access Control • Attribute Based Access Control • Delegated Access Control with OAuth 2.0 Typically, every business, enterprise or organization is divided into groups of employees around related business functions. This group information can be used when software Users interact with an App and you need to restrict their access according to the authorization or access control rule in place for that software. You can use the group they belong to in order to identify their role when using the App. Going beyond the static assignment of roles to Users based on the organizational groups to which they belong, Attribute based Access Control (ABAC) aims to facilitate the dynamic determination of access control based on some sort of circumstantial information available at the time of the API call. The HTTP based OAuth 2.0 framework allows an App to obtain access to a resource exposed by your API either on its own behalf or on behalf of the User who owns the resource. Thus it allows Users to delegate access control to third party Apps.
- 9. All contents © MuleSoft Inc. Identity > Federated Identity 9 • Single Sign-on • SAML 2.0 • OpenID Connect The token based approach to authentication allows for the separation of the issuing of tokens from their validation and thus facilitates the centralization of Identity Management. The Security Assertion Markup Language (SAML) is an industry standard which has become a defacto standard for Enterprise level Identity Federation. It allows Identity Providers to communicate authentication and authorization information about Users to Service Providers in a standard way. OpenID Connect is built on top of OAuth 2.0 to provide a Federated Identity mechanism that allows you to secure your API in a way similar to what you would get were you to exploit WS- Security with SAML.
- 11. All contents © MuleSoft Inc. Main Security Concerns 11 • Integrity • Confidentiality • Availability • Users, Apps • Clients and Servers
- 12. All contents © MuleSoft Inc. Main Security Concerns > Integrity 12 • Digital Signatures • Message Safety Message Integrity goes beyond the authentication of the App and the User and includes the verification that the Message was not compromised mid-flight by a malicious third party. In other words, the Message received by your API is verified as being exactly the one sent by the App. The same goes for when your API acts as Client to a Server.
- 13. All contents © MuleSoft Inc. Main Security Concerns > Confidentiality 13 • Public Key Cryptography • Digital Certificates • Mutual Authentication • HTTPS It is all very well to rest assured with the Integrity of a message sent by a known App, but the journey from App to API may have been witnessed by some unwelcome spies who got to see all of those potentially very private details inside the message! Thus, it is necessary to hide those details from the point of delivery by the App to the reception by the Server. An agreement is needed between the App and API in order to be able to hide the details of the message in a way that allows only the API to uncover them and vice versa.
- 14. All contents © MuleSoft Inc. Main Security Concerns > Availability 14 • Load balancing • Clustering • Reliability Your API must guarantee that it is always available to respond to calls and that once it begins execution on the call, that it can finish handling the received message right the way through to completion without losing data. This can be achieved by horizontally scaling the API across multiple servers and by handing off the processing of the message to a message broker which will hold the message till the API has completed its processing. The understanding in this latter scenario is that another process is subscribed to this message publication and thus continues the processing asynchronously.
- 15. Mule Runtime Security Capabilities
- 16. All contents © MuleSoft Inc. Mule Runtime > Confidentiality 16 • Mule HTTPS Connector • Mule Encryption Processor • Dynamic Data Filtering with DataWeave An HTTPS listener can be configured with reference to a keystore so that your API can authenticate itself to the App. When client authentication is demanded from the App, the listener can reference a truststore. The Mule Message Encryption Processor can change the content of a message so that it becomes unreadable by unauthorized entities. Mule can encrypt the entire payload of a message or specific parts of the payload, according to security requirements, using different encryption strategies. DataWeave is Mule’s data transformation engine which transforms between different mime-types using a simple expression language which is common across all data formats. The language can be used to remove and / or mask data fields in the payload, whatever the structure of the payload and the location of the field.
- 17. All contents © MuleSoft Inc. Mule Runtime > Integrity 17 • Mule Security Manager • Mule Secure Token Service OAuth 2.0 Provider • Mule Digital Signature Processor • Mule Credentials Vault Exposing your API over HTTPS guarantees that it has not been modified in transit. However, authentication and authorization of the request still need to take place. Central to authentication in Mule is Mule Security Manager. This is the bridge between a standard mule configuration and Spring Security beans. Mule can act as an OAuth2 Provider, issuing tokens to registered Apps, applying expiration periods to these tokens and associating them to User roles and fine-grained access control known in the OAuth world as scopes. Mule Digital Signature Processor adds a digital signature to a message payload, or part of the payload, to prove the identity of the Message’s sender. Mule Credentials Vault is for the encryption of properties that are referred to and decrypted by the Mule application at deployment time.
- 18. All contents © MuleSoft Inc. Mule Runtime > Availability 18 • Mule HA Clusters • Anypoint MQ A single Mule server hosting your API is not enough to facilitate high availability. To achieve this, you need to host the same API on more than one Mule runtime. With a load balancer in front of the API, you can guarantee that the API will always handle incoming requests as the load balancer chooses between those instances which are healthy. Reliability on Mule can be achieved by clustering two or more instances of Mule together which is easy using Anypoint Runtime Manager. For reliable processing of Messages between multiple APIs you can use Anypoint MQ.
- 20. All contents © MuleSoft Inc. Anypoint Platform > API solution 20 • API Adapability with Policies • Anypoint Gateway communication • Security Policies • Custom Policies Anypoint Platform API Solution is a fully multi-tenant application running on top of Amazon Web Services (AWS) and inside a VPC (cloud VPN). Although Anypoint Platform can manage and enforce the runtime security of your API, the API itself remains wherever you have it deployed. Using the Mule runtime as an API gateway you can host your API. The Mule runtime communicates constantly with Anypoint API Manager to retrieve policies and report back analytical information about the usage of your API. Anypoint Platform returns to issues of Identity when addressing its specific security policies. Policies on the Anypoint Platform are snippets of Mule Configuration. As such, custom policies are very easily configurable and can be surfaced on the API Manager portal as siblings to our out-of-the-box policies.
- 21. All contents © MuleSoft Inc. Anypoint Platform > MQ 21 • Cloud Messaging • Multi-tenant • Multi Datacenter persistent Storage • Encrypted Exchanges and Queues Anypoint MQ is a multi-tenant cloud messaging service offering persistent data storage across multiple data centers, ensuring that it can handle data center outages and have full disaster recovery.
- 22. All contents © MuleSoft Inc. Anypoint Platform > Virtual Private Cloud 22 • Your DataCenter + Anypoint iPaas • Single Private Secured Network • IPSec • OpenVPN • Amazon VPC peering Mule applications can be deployed either to your on-premises Mule runtime or to our fully hosted and fully managed iPaaS. In most scenarios, Mule applications deployed to the iPaaS will need to integrate with systems in your datacenter. In some cases a hybrid architecture is adopted where Mule applications deployed to the iPaaS must integrate with Mule applications deployed to Mule runtime on-premises. Virtual Private Cloud (VPC) enables you to connect your organization in Anypoint Platform to your corporate data centers – whether on-premises or in other clouds – as if they were all part of a single, private secured network. You can configure these networks at hardware or software levels. VPC can be configured to use IPSec, TLS (over OpenVPN) or Amazon VPC peering to connect to your on-premises data centers. IPsec connections can be configured at the hardware level in addition to a software client.
- 23. All contents © MuleSoft Inc. Anypoint Platform > User Roles and Permissions 23 • Organizations and Business Groups • Separate API Management • Separate Runtime Management • Roles and Permissions per Organization / BG • Federated with External Identity Providers In Anypoint Platform, users belong to an organization and have a set of roles and permissions. API versions and deployment environments are grouped under organizations. To access them you need to have an account that that owns the necessary permissions and that belongs to its corresponding organization – and to the Business Group if the resource exists in one. Roles and permissions can be granted for accessing resources that exist in the master organization, or for resources that exist within a Business Group. A user that owns any role of a business group is implicitly granted membership in the Business Group. Each role contains a list of permissions that define what a user that holds that role can do with the specific resources it scopes. Permissions can also be added at an individual user level. Keep in mind that API permissions are API version specific and iPaaS permissions are environment specific – they grant you the ability to do something within a particular API version / environment, not the entire organization.
- 24. All contents © MuleSoft Inc. Anypoint Platform > Security Compliance 24 • FIPS 140-2 • SSAE 16 SOC 2 • PCI DSS Level-1 • HiTrust When Anypoint API Manager manages APIs from the cloud, it stores only metadata about the APIs and the Apps which consume them. The APIs can be deployed on the Mule runtime either on-premises or in our fully hosted, fully managed iPaaS solution. The extent to which Anypoint Platform platform is compliant with external audits is detailed in the whitepaper “Anypoint Platform Cloud Security and Compliance”.
- 25. Summary Scenario
- 26. All contents © MuleSoft Inc. Scenario problem 26 Mythical Retail has a chain of stores and deliver an e-commerce solution to their customers. One of their business objectives is to increase ecommerce revenue by 20% in the next 18 months. Mythical wants… Mythical has… An omnichannel digital strategy Anypoint Platform for integration and API management A single view of the customer Clienteling software to help sales associates A loyalty program to understand their customers spending habits Uniformity across all customer touchpoints How can this be secured?
- 29. All contents © MuleSoft Inc. Scenario solution 29 1. Katie signs in to her iPhone App. 2. Part of the digital solution catering to Katie’s experience is the My Shopping API which delivers all the relevant capabilities to her iPhone App. This API is protected with the PingFederate access token enforcement policy. In order to consume the My Shopping API, the iPhone App must interact with the PingFederate Authorization Server to request an OpenID Connect token on her behalf. PingFederate authenticates her credentials against Active Directory. Upon successful authentication, it generates a token and signs it (see Digital Signatures 2.1.1) before responding to the iPhone App with the token. The App presents this token in a custom HTTP header on every subsequent call to My Shopping API. 3. All calls between experience, process and system APIs are protected with the client ID enforcement policy. Each API has an ID and secret stored in Mule Credentials Vault. 4. The calls to the Tokenization API are protected with client cert authentication and the payload passed to the API is encrypted and signed with Mule Encryption Processor and Mule Digital Signature Processor respectively before sending. 5. Publications to Anypoint MQ are protected with OAuth 2.0 and HTTPS. 6. Subscriptions to Anypoint MQ are protected with OAuth 2.0 and HTTPS. 7. There is a federated trust between the Identity Providers in both security contexts for Mythical Retail and its shipping partner. Both the sales associate’s App and Katie’s App can call the Order Tracking API with the access token that they received from PingFederate. The Order Tracking API validates the token with OpenAM, the Identity Provider of the shipping company. This is able to verify that the token was signed by the Identity Provider of Mythical Retail, which it trusts. The Order Tracking API accepts the invocation by the iPhone App and responds accordingly. 8. Sales associates use multi-factor authentication to sign in to their App. The App calls PingFederate OAuth 2.0 authorization server to get a token which it passes to the Shop Assistant API. 9. Interaction with the systems of record is secured in various forms according to the requirements of each Server. Tokens and username and password credentials are stored in Mule Credentials Vault.
- 30. All contents © MuleSoft Inc. In Conclusion 30 APIs are a strategic necessity to give your business the agility and speed needed to succeed in today’s business environment. But with the increasing cost of security breaches, senior IT decision makers quite rightly want assurances that exposing their data via APIs will not create undue risk. Anypoint Platform’s features provide the necessary assurances for the confidentiality, reliability and availability of APIs designed and managed on the platform. Anypoint Platform is trusted by industries needing the highest levels of security, including 5 of the top 12 global banks, 2 of the top 5 global insurance companies and top pharmaceutical and global healthcare companies. For more resources on API security, please take a look at our whitepaper and webinar on API security best practices.
- 31. Thank You