Recommended Patterns for onboarding SaaS applications – Part 1

Connecting all the right software as a service (SaaS) providers using well-established private, secure and resilient integration patterns can seem overwhelming. The SaaS model of deployment can help organizations reduce undifferentiated heavy lifting to manage the vendor’s application, software tools and hardware infrastructure—resulting in an improvement in operational efficiency and business agility.

We, at Amazon Web Services (AWS), are seeing an increased adoption of SaaS independent software vendors (ISVs) by our customers for both functional and non-functional requirements. For example, our Financial Services Institutions (FSI) customers are looking at SaaS ISVs for customer onboarding, electronic know your customer (eKYC), payments, core banking systems and more.

From a non-functional perspective, they are looking at SaaS vendors for security, operations, reliability and maintainability. The growing number of SaaS vendors operating within an organization has created a unique challenge around managing the complexity and overhead of a large number of SaaS integrations.

This two-part blog series will take you through various patterns of SaaS integration that were successfully implemented at some of our larger customers, and can be used by your organization too. Consider these patterns as an extension to the existing landing zone which you might have on AWS.

In the first part of the series, we will be looking at foundational and key management patterns of SaaS integration. In the second blog we will look at data sharing patterns.

Foundational Patterns

As enterprises set up their cloud platform to onboard and consume SaaS workloads, there are key foundational patterns that need consideration. You can see these patterns in the following diagram (Figure 1).

Figure 1. Foundational Patterns

Centralize networking by using a common virtual private cloud (VPC) for all SaaS providers: At a networking infrastructure level, a useful pattern is to use a common VPC for your SaaS providers within a central AWS SaaS network account. This will allow you to segment this VPC for different SaaS providers by the use of subnets while centralising networking controls and operations within one VPC (Figure 1, item 1).

Ingress and egress traffic management can be governed centrally in this VPC, such that all traffic flowing to and from SaaS providers will undergo the same flow management (including capturing VPC Flow logs). The traffic landing points will be provisioned through AWS PrivateLink endpoints (other options are possible but outside the scope of this blog post). It provides strong segregation between your AWS Account and the SaaS provider’s AWS Account, without shared components and allowing for overlapping CIDR blocks. Traffic flowing from a SaaS provider through PrivateLink has the extra benefits of staying completely on the backbone of AWS, resulting in lower latency, consistent network performance and enhanced security.

If services are required to be exposed to SaaS providers (for example, SaaS providers requiring to talk to internal customer systems), it is recommended to consider a similar pattern of exposing AWS PrivateLink endpoints. Then you get the same benefits of a private network built on the backbone of AWS. To expose an AWS PrivateLink endpoint, there would need to be a Network Load Balancer provisioned and managed in the common VPC.

Implement fine-grained traffic control using security groups: Use security groups and security group rules to control traffic that is allowed for ingress and egress (Figure 1, item 2). For outbound traffic, you can use security groups to control which ports, protocols and sources in your organisation are allowed to talk to the SaaS provider through PrivateLink by associating security groups to your PrivateLink interface endpoint. For inbound traffic from the SaaS provider to your internal systems over PrivateLink, you can control traffic by associating a security group with your Network Load Balancer and enable inbound rules on PrivateLink traffic. This will consider the private IP address of the client (your SaaS provider’s systems) as the source, not the endpoint interface.

Manage Network Inspection: For traffic inspection, consider using firewall subnets, where you can use AWS Network Firewall for traffic filtering (Figure 1, item 3) or host Gateway Load Balancers. AWS Network Firewall is the native AWS service that can be used to implement firewall rules for SaaS-based traffic. Gateway Load Balancers will let you use the network appliance of your choice from the variety of partners currently supporting this service on AWS.

When using these firewall options, it is also important to optimise the configuration of traffic flow through the VPC subnets to ensure cost management and allow for symmetric routing. By deploying subnet specific routing, you are able to keep SaaS traffic, up to the point of connecting to the transit gateway attachment, wholly within a single Availability Zone. This helps ensure a cost effective data transfer for your traffic within the VPC. This pattern can be deployed across multiple Availability Zones to meet your resiliency requirements.

Reduce blast radius using account level isolation: At an account level, it is recommended to apply the pattern of operating a separate AWS Account per SaaS provider. This separate bridge AWS Account for each SaaS provider will contain specific AWS services and resources that should be isolated and separated to match the operating model like S3 buckets or AWS Key Management Service (AWS KMS) keys (Figure 1, item 4). Many enterprise customers operate separate teams per SaaS provider, especially as the provider may be more aligned to business focus areas from various parts of the organisation.

The clear boundary of an AWS Account will offer the blast radius management control which large enterprises often require for their workloads. Any issues and incidents can be contained within the account, as opposed to possibly affecting the entire enterprise. The SaaS workload will not naturally be able to see, operate, or even be aware of other services and resources in other AWS Accounts (and by application of this pattern, other SaaS providers) in the enterprise, unless explicitly allowed to do so.

The principle of this isolation at the AWS Account boundary also applies to the AWS Identity and Access Management (IAM) roles and policies in the SaaS bridge AWS Account. The IAM policies and identities will be inherently scoped to the AWS Account it operates in, again limiting the scope of any unintentional misconfiguration or malicious intent affecting these resources.

The AWS Account boundary also offers the benefit of being able to identify the telemetry that is relevant for the SaaS provider it is bridging to. The AWS CloudTrail logs, which shows specific API access for AWS services and events, will help partition the audit trail for the specific SaaS provider only. This allows you to dive into the issues and incidents as they occur. Similarly, the Amazon CloudWatch logs that are associated with any AWS services in the bridge AWS Account are also specific to the SaaS provider. This helps with any deep dives into the logs and metrics to uncover insights or incidents.

Overall, these are foundational patterns to set up onboarding and consuming SaaS provider applications in a large enterprise. The patterns focus on the core concerns of network access and AWS Account configuration to help with the structure of a customer’s cloud platform to treat SaaS workloads with the same controls as the rest of their AWS services.

Key Management Patterns

Setting up the networking foundations and account structure gives you a strong base to build the key management patterns for SaaS workloads. The ability to bring your own key (BYOK) is an important security measure for some of our customers. They retain ownership over their keys to better manage the control they have of the data stored by their SaaS providers. This is often difficult with SaaS workloads as it involves a complex protocol for exchanging and cycling of keys. This often doesn’t provide any visibility of the usage of the keys beyond the handover ceremony.

Using AWS services, we can carve out a pattern for BYOK to AWS hosted SaaS providers that will mitigate some of these challenges around provisioning, rotating and revoking of encryption keys. There are two variations of this pattern:

BYOK using AWS KMS: Given the strong blast radius boundary with AWS Accounts (which will segregate resources and roles per SaaS provider), we should take advantage of this to house and share encryption keys. As for the following diagram (Figure 2), the pattern of setting up an AWS KMS instance within a bridge AWS Account dedicated to a SaaS provider helps ensure that it will only be used and operated by a controlled set of users and services.

Figure 2. Key Management Pattern – BYOK using AWS KMS

An AWS KMS key created within this AWS KMS instance can then be shared with SaaS providers on AWS through an appropriate IAM policy that only allows access to a role within the SaaS provider’s AWS Account. After you share the AWS KMS keys, you are then able to track the usage of the AWS KMS keys through AWS CloudTrail. Every time the SaaS Provider role/user makes a request for the AWS KMS key, you are able to see an attestation of this in your CloudTrail logs, which can be located by the SaaS provider through the bridge AWS Account.

In addition, large enterprises can now control the cycling and validity of those keys, which can be rotated and cancelled at will. This pattern significantly improves the position large enterprises have in being able to bring their own keys for use by their SaaS providers, specifically if those SaaS providers are on AWS and are supporting this pattern.

BYOK using AWS CloudHSM: Some customers might require hardware security modules (HSM) for security or compliance reasons to generate and store encryption keys. You can apply the same pattern to provide an AWS CloudHSM instance to your SaaS providers (Figure 3).

Figure 3. Key Management Pattern – BYOK using AWS CloudHSM

Take advantage of the blast radius boundaries available in the dedicated bridge AWS Account for your SaaS provider by creating a separate VPC within this account. Instantiating a CloudHSM within this VPC gives it several layers of isolation, such that you could safely peer that VPC with a SaaS provider. This will give you the ability to control the key material they use. This peering connection is entirely within your control and access can be revoked/modified without involvement of the SaaS provider.

A custom key store connector could also be used to connect the CloudHSM cluster to an AWS KMS instance so there is no need for VPC peering. However, that limits you to encrypt and decrypt operations and does not support CloudHSM specific cryptographic tasks like asymmetric decryption, signing or HMAC.

These key management patterns illustrate the ability of large enterprises to better manage the controls they have around the encryption of data stored by their SaaS providers. It is particularly beneficial if those SaaS providers are on AWS and help specifically with management of the keys and attestation of their usage. It is these controls which help large enterprises manage some of the risks around using SaaS providers in the same way they would manage the risks around hosting their own workloads in AWS. Establishing the foundations to use these patterns will also help onboard SaaS providers much faster going forward.

Summary

In this blog post, we illustrated foundational patterns to standardize the way you connect with SaaS Providers covering networking, AWS Account setup and key management to improve operations, security and control of data stored by these SaaS providers.

In the second part of this two-part blog series, we will focus on data sharing patterns.

Contact an AWS Representative to know how we can help accelerate your business.

Further Reading

• AWS Prescriptive Guidance: Integrating third-party services in the AWS Cloud discusses different individual architectures that you can use to integrate third-party services in the AWS Cloud including the use of PrivateLink (Figure 1) as applied in this blog post
• Check out Deployment models for AWS Network Firewall with VPC routing enhancements for in-depth information on how to implement this with VPC routing rules and AWS Network Firewall.
• Share Custom Encryption Keys More Securely Between Accounts by Using AWS Key Management Service
• When to use AWS CloudHSM
• How to deploy CloudHSM to securely share your keys with your SaaS provider

Acknowledgements

We’d like to thank Minh Yie (former AWS Solutions Architect), who did a lot of the groundwork on these patterns and contributed to the creation of this blog.