You agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

How to Protect Customers' Secrets in Your SaaS Offering: Detailed Guide

Privacy
Table of content:
Join our newsletter

Your privacy is important to us, privacy policy.

Introduction

As a SaaS provider, you may offer your users integrations with third-party services or be thinking of doing so, whether to provide an intrinsic feature or add capabilities to improve your product’s competitive edge. These integrations can range widely. Relatively low-impact integrations can include pushing messages into a customer’s Slack channel or reading calendar entries. Other integrations go further, such as making a financial transaction on your clients' behalf using an Automated Clearing House (ACH) transfer or open banking.

However, whatever the integration, they all have something in common: as the provider of the SaaS, you need to request a secret access token from your customer and store it to enable your application to access the third-party system. This requirement creates an obligation on you to protect the secret.

Reflect is requesting permission to access the workspace

This post explores the options available to safeguard your customers’ secrets.

Why protecting customers’ secrets matters

So, what is a secret? A secret is anything needed to authenticate a user to a service. Broadly, the secrets could include database or system usernames and passwords, but typically, for a SaaS integration, it's likely to be an OAuth token and secret. 

If it needs to be clarified why protecting customer secrets matters, consider the recent Heroku breach/leak. This incident started with a threat actor gaining access using a compromised token from a Heroku machine account. This breach went unnoticed until GitHub notified Heroku’s security team of a potential issue. Heroku’s investigation revealed that the threat actor accessed a Heroku database and downloaded customers’ GitHub integration OAuth tokens.

A similar data breach occurred at Sisense, a business intelligence company. Attackers gained access to the company’s internal Gitlab code repository. In there, they found a token or credential that gave them access to Sisense’s Amazon S3 buckets. From there, the bad actors accessed customer data, including access tokens, email passwords, and SSL certificates. This event triggered an investigation by the US Cybersecurity and Infrastructure Security Agency (CISA), given that Sisense customers include critical infrastructure sector organizations.

The severity of these incidents would've been much reduced if those companies had appropriately secured their customers’ secrets.

Choosing the right level of protection

You might think, “But this is straightforward: My database is protected, so I'll just put the secrets in there.” or “I can use one of those secrets manager products.” Unfortunately, it's not that straightforward.

When I talk to potential customers, I describe the levels of protection using four categories: basic, field-level encryption, employing secret managers, and using a vault.

Level 0: Basic

Basic is the lowest level of protection and, sadly, one of the most common. At this level, your application database stores secrets in plain text. 

This approach has the obvious advantage that the secrets are easily accessible along with the other information you need to implement your application. However, this easy accessibility is simply asking for a data breach. As the secrets are not protected, anyone who can access the database can access the secrets. And don’t think that encryption at rest provides any meaningful protection

In addition, this approach offers limited access control; someone either gets access to all or nothing. So, if the application is compromised, all data is compromised. There's also no audit mechanism, so you cannot even see who's used the secrets.

Level 1: Field-level encryption 

The next level of protection also uses the application database but adds field-level encryption to the secrets. Now, someone who accesses the database won't be able to see the secrets without also compromising the encryption mechanism. 

However, this approach has the same issues with access control and auditing as the basic use of a database; it requires encryption key management, including key rotation and key access. If you don't do this correctly, a threat actor can easily compromise the encryption or the application.

Level 2: Secrets manager

Using a secrets manager or parameter management tool such as AWS Systems Manager (formerly Amazon Simple Systems Manager (SSM)) is stepping things up a level. These tools provide a significant improvement over field-level encryption. Customer secrets benefit from a mechanism that ensures the encryption keys are never exposed and the keys are managed appropriately. 

Now, there is an added operational cost, but it can be cost-effective for relatively modest requirements (less than 100,000 secrets). However, these products were never designed for this purpose, so they may not provide the throughput and response times your application needs.

Level 3: Vault

You can achieve the highest level of protection using a vault. In this case, you also hand off the storage of the secrets to a third party. Using a vault, you benefit from managed encryption keys, like a secret manager or AWS SSM. In addition, you can get features such as granular access control, audits, and proxy or relay APIs. A proxy or relay API uses the stored secrets to connect to a third party at your application's request. This mechanism means your application doesn’t see the secret, reducing the risk of exposing customers' secrets should someone compromise the application. 

The developers of this type of product engineer them for high throughput and optimal response times. This option should also be more cost-effective when managing more than 100,000 secrets.

Protection level Secret location Access is given by Pros/cons
Basic Application database as plain text Database -> secret + Easy access
- Secrets aren’t secured, no audit
Field level encryption Application database as an encrypted field Database + Encryption key -> secret + Data in the database is encrypted
- Need to manage encryption keys, rotation, access to keys
Secrets manager
[Also AWS SSM]
As an encrypted value in the Secret Manager or SSM. Database + service that decrypts the secret -> secret + Encryption key is never exposed
- Limited RPS, pricing, volume, size
- Hard to scale ACLs for services X secret types per customer
- No leak prevention
- No data minimization
Vault
[Proxy/relay]
Vault as an encrypted field Access control and decryption -> secret
[Access control]
+ Secret is never exposed+ Easy to manage access over many types of keys
+ Expiration, retention, data minimization
+ Cross-tenant leak prevention, masking, tokenization
+ Detailed audit log

This table looks at the features provided by each option in more detail.

Requirements / Strategies Basic Field-level encryption Secret manager Privacy vault Privacy vault with API relay
Easy access
High throughput
High volume (price efficiency)
Data minimization
Secure storage
Audit logs
Scalability
Disaster recovery
Compliance with regulations
Automatic expiration
Granular access control
Data masking
Leak prevention
The secret is never exposed

How Piiano Vault can help

We designed Piiano Vault to protect sensitive and personal data for virtually any application. It is a purpose-built vault with a relay API that provides all the features needed to protect customers’ secrets securely. It is also designed with zero trust principles, so even if the application is compromised, it doesn’t necessarily mean all secrets are compromised, as is usually the case today.

Click here to learn more about Piiano Vault

Conclusion

A significant contributor to a SaaS offering's success is its ability to engender trust with potential and active customers. Where that service includes third-party integrations, building that trust means providing best-practice protection for those customers' secrets.

The best practice solution is to use a privacy vault to store, encrypt, and manage access to those secrets without easily exposing them.

Piiano Vault is a cost-effective way of implementing these best practices. It can be implemented in server or serverless versions to encrypt and tokenize customer secrets. 

In future blog posts, we will explore some of the practicalities of implementing best practices for protecting customers’ secrets with Piiano Vault. In the meantime, check the documentation or contact us today to find out more.

Further reading

Share article

Powering Data Protection

Skip PCI compliance with our tokenization APIs

Skip PCI compliance with our tokenization APIs

hey

h2

link2

It all begins with the cloud, where applications are accessible to everyone. Therefore, a user or an attacker makes no difference per se. Technically, encrypting all data at rest and in transit might seem like a comprehensive approach, but these methods are not enough anymore. For cloud hosted applications, data-at-rest encryption does not provide the coverage one might expect.

John Marcus

Senior Product Owner

const protectedForm = 
pvault.createProtectedForm(payment Div, 
secureFormConfig);
Thank you! Your submission has been received!

We care about your data in our privacy policy

Oops! Something went wrong while submitting the form.
Submit