Control Access to Sensitive Data

Introduction

For all the MuleSoft APIs that are developed, it is important that they are made available in a secure manner. MuleSoft Anypoint Platform’s API manager is used in applying security policies on the MuleSoft APIs.

At present, the policies like JWT Validation, Rate Limiting, Client ID Enforcement, etc., focus on authentication and authorization of the API consumers which is of course an important part of security. However, there is a need to also check if the data being returned in the API response is sensitive and to check if the API consumer is authorized to view that sensitive data.

One of the ways to secure such scenarios is through building a custom policy in API Manager. This custom policy will suppress any sensitive data from flowing back to an unauthorized user.

API Manager Policies

The following diagram depicts how API manager policies are managed separately from the API implementation. Also as is shown below, most of the policies are applied on the request path of the API invocation. In the request path, there are policies applied that will allow or disallow users to call the API.

There might be scenarios where even though the user is authorized to invoke the API, they may not be authorized to read the entire set of data. For unauthorized users, sensitive data should be suppressed. This can be made possible by building a data classification custom policy and then applying this policy to all the applicable APIs via the API manager.

Standalone Custom Policy

In a few scenarios, the requirement for suppressing data could be static wherein irrespective of API consumers or end-users, sensitive data should not be returned in the response.

This policy like other API manager policies will be separate from API implementation and so, the API implementation need not handle any logic on which user should have access to which data.

As depicted in the diagram below, since the custom policy is configured to suppress dateOfBirth and taxFileNumber, these fields get suppressed in the response.

Custom Policy with a Common Service

There are other more complex scenarios where based on the end-user, the data being returned may have to be suppressed. For such cases, apart from a custom policy, there will be a common service and a database required that will return if any of the fields need to be suppressed.

When the APIs are protected using OAuth providers, the incoming JWT tokens have a lot of information that could be used by the common service.

High-Level Design

The custom policy and the common service will rely on a JWT token that will be passed to the API. JWT token will need to have scopes that allow reading the fields that are defined as sensitive.

Custom policy will pass the JWT token and the API name to the common service. The common service will then retrieve the list of sensitive fields defined for the API in the databsae.

The database will maintain information about:

–  Names of fields that are sensitive.

–  For a given OAuth Scope, names of the sensitive fields that are allowed to be passed in the response.

The common service will inspect the JWT token and based on the defined scopes and sensitive fields combination, it will return if any of the fields in the API response should be suppressed.

The custom policy will then modify the response to suppress any of the fields that were returned by the common service.

Caching will be used to reduce number of invocations to database and also to reduce number of invocations to the common service