One way to enhance your API security on Amazon Web Services (AWS)

APIs have been at the heart of many of the high-profile data security breaches of recent times
Mutual Transport Layer Security (mTLS) on Amazon Web Services (AWS) adds an extra layer of protection
It can help prevent multiple types of cyber attack

Application programming interfaces — more commonly known as APIs — are fundamental to the success of leading businesses in the digital age. The mechanisms that enable two software components to communicate with each other, they connect companies on the web and enable mobile experiences. Each time you look up the weather on your phone, an API is ‘talking’ to the Australian Bureau of Meteorology so that it can show you the weather forecast.

Unfortunately however, APIs have been at the heart of many of the high-profile data security breaches of recent times. It is our view that cloud-based API endpoints require far more attention from organisations in business impact assessments, security reviews and audits.

Why mTLS on AWS?

Mutual Transport Layer Security (mTLS) on public cloud providers such as Amazon Web Web Services (AWS) is a good starting point. It can be used to supplement all other controls in identity, application security and network infrastructure protection, forming the foundation of a ‘defense in depth’ approach to API security.

Most digital practitioners today treat ‘Encryption In Transit’ as the gold standard. When a digital system goes through a security review or audit, almost certainly, this gets asked as part of the checklist. But is your digital system secure, simply by loading a Transport Layer Security (TLS) certificate, even with the latest version 1.3?

The traditional TLS encryption only requires the client to verify the server certificate during the establishment of the connection. This is not enough for mission critical applications such as API to API communication that require a higher level of security and enforces a ‘Zero-Trust Model’. The client’s identity is also required to be verified. Mutual TLS (mTLS) came into existence to fix that issue. Before the connection is established, both client and server need to mutually present their certificates and get them verified by the other party. This is effectively double hand shaking.

To ease the deployment of mTLS, AWS has provided some seamless native support including the load balancing service, certificate manager and its storage services. Let’s explore what risks mTLS on AWS may help mitigate, and consequently, some examples of AWS services that could build a well architected and managed digital system with heightened security.

Use-case for API security

For web services that mostly provide services via a server to client (user or system), mTLS might be an overkill. Having credentials plus another factor of authentication, or multi-factor authentication may suffice in ensuring the identity of the client.

However, when the interaction pattern between two sides are less asymmetric, meaning both sides can initiate the communication and may invoke a service on the other side, or may upload and download information bidirectionally, it is more important to have both sides authenticated as part of the TLS handshake process when the connection is being established. Furthermore, often those digital systems are APIs on both ends, forming a service-to-service relationship. Therefore multi-factor authentication is not always applicable while the same rationale will apply to IoT machine-to-machine communication.

With mTLS in place, it helps to address some risks in API to API communication when the API key is used as the sole or main method of authentication. When mTLS is enabled, having a valid API key while failing authentication to present a valid certificate, the communication link will not be established and requests will be denied.

It can help prevent:

Brute force attacks on the API key
Man-in-the-middle or on-path attacks
Spoofing attacks with stolen credentials

Support services from AWS to help you achieve heightened security

Application Load Balancer (ALB)
Introducing this as a relatively new feature, ALB now supports both pass-through and verified mode for mTLS. Under verified mode, ALB performs X.509 client certificate authentication for clients when a load balancer negotiates TLS connections. This feature offers an alternative to application-based authentication. Application-based authentication is usually implemented via an EC2 instance (virtual machine) or a container in the server backend. ALB-based verification offloads the compute and traffic load from the server backend and is a more scalable solution requiring little to no management overhead.

API Gateway (APIG)
APIG supports mTLS authentication, along with other authentication and authorisation operations such as JSON-web Token (JWT), a way for the application to digitally sign a payload for its integrity. APIG can also forward the certificates provided by the client side to Lambda authorisers and other backend integration services.
AWS Certificate Manager Private Certificate Authority (ACM PCA)
Either third party Certificate Authority (CA) signed certificates bundles, or ACM PCA signed ones can be uploaded for mTLS authentication.
Amazon S3 (S3)
ALB requires a TrustStore for the mTLS authentication. S3 buckets can be used for this purpose. All security controls built around IAM, bucket policies and Access Control List (ACL) still apply when securing the access to the file.

In summary, if you have cloud-based applications and digital systems, mTLS on Amazon Web provides a robust and secure mechanism for authenticating and encrypting communication between clients and servers. It adds an extra layer of protection, an imperative in today’s operating environment.