How to Ensure SaaS Data Security with Curated Database Design

To make sure your SaaS product will be in demand, it’s essential to listen to customers’ needs and focus on software security. With data security threats on the rise, organizations pay close attention to cybersecurity measures when choosing which SaaS solution to purchase. According to the State of SaaS Security: 2023 Survey Report, 55% of respondents experienced a security incident within their SaaS ecosystem in the past two years. And data leakage constitutes 58% of all incident types.

Thus, establishing top-notch data protection for your SaaS product is just as important for your software’s success as user-friendly design, a rich feature set, and attractive prices. And to ensure that protection, it’s essential to thoroughly plan the database structure and apply top-notch protection mechanisms to prevent data leaks. You also need to make sure developers can efficiently support the software without access to real user data.

In this article, we describe the role of database design in SaaS security and explore common database structures in detail. We also discuss proven ways to protect data in storage and during software maintenance.

This article will be helpful for development and project leaders who want to know more about establishing robust SaaS data security when building solutions, starting from the database structure design stage.

The role of database structure in SaaS data security

SaaS providers hold significant responsibility for a solution’s efficiency and security. They need to conduct environment maintenance in a timely manner, restrict outside access to data and resources, etc. If you’re going to create a SaaS product, keep in mind that your customers (also called tenants) trust you with their corporate and user information, expecting your software to offer robust data protection along with software efficiency.

One of the key decisions you need to make to ensure the safety of customers’ data is which database structure to use for your SaaS product.

Why does database structure matter?

A database layer is what allows your team to provide data management and storage as well as to handle infrastructure, including servers, networks, and storage devices. The way you structure and organize databases defines your SaaS product’s performance and scalability capabilities.

Since SaaS solutions require data from multiple tenants to reside within their databases, picking the right structure is the primary factor to consider when designing your database. The chosen structure will impact the ability to scale the database up and down and handle increasing workloads.

You should also take into account that your choice of database structure will directly impact the cost of your services for end users. So, if you want to leverage price as your competitive advantage, you might want to consider less resource-hungry options.

Let’s briefly describe the key impacts of database structure on a SaaS product:

• Data safety. The more types of sensitive data your software is supposed to store and process, the more effort developers have to put into protecting it. For example, SaaS solutions that include handling any financial operations must be thoroughly protected, as they deal with adding and storing users’ banking information like credit card numbers, banking accounts, etc. Some database structures provide opportunities for stronger data security, so you can start planning SaaS data protection during the database design stage.
• Data isolation. SaaS customers must only interact with their own data. No tenant should see other customers’ information, not to mention have access to change it. Different approaches to database organization lead to different levels of data isolation, so you need to keep data isolation requirements in mind when choosing the database model.
• Performance. Customers expect SaaS products to work smoothly and ensure a consistent user experience, but achieving this isn’t easy. For example, any additional logic for operations (like masking or extracting even a single user’s data) requires additional actions from a SaaS solution. And the increasing number of actions or the need to move massive volumes of data can slow down SaaS product response. So, if your SaaS system targets large organizations that work with tons of data all the time, you might need to choose a database structure that provides independent resources for each tenant.
• Noisy neighbor effect. Keep in mind that customers are different: some operate large businesses and interact with SaaS solutions 24/7, while others use purchased software to only process a couple of operations per day. Your team needs to make sure that the way one customer uses SaaS resources won’t affect the work of others. Below, we explore the probability of this occurrence for each database model.
• Scalability. As the number of users grows, their needs and requirements will grow as well. And your team will need to provide scalability opportunities for customers. It’s essential to smartly choose how to expand your product’s resources: by increasing the quantity of resources or increasing the power of existing resources. With some database structures as the basis of your SaaS system, it can be difficult to scale customers’ applications, so you need to choose wisely.
• Customization capabilities. The more customers your SaaS product attracts, the more chances some of them will ask for additional or augmented features. The reason is that many businesses handle operations in ways that aren’t covered by standard SaaS solutions. If you manage to create an architecture that allows you to customize existing features with ease, you can significantly increase your software’s competitiveness. The database model you choose can significantly impact your software’s customization capabilities.

Knowing the importance of a wisely chosen database structure, let’s explore the main database models — single-tenant and multi-tenant — and highlight their pros and cons in regards to software efficiency and data security in SaaS.

1. Single-tenant model: pros and cons

The single-tenant model, also called standalone, ensures independent resources for each tenant. This means that every customer of a SaaS product receives a dedicated software instance, a single infrastructure, and one database exclusively serving their entity.

Since the entire development environment is dedicated to one customer, there’s no resource sharing, which is good for data isolation and safety, customizability, application efficiency, and SaaS security and data management. On the downside, this model leads to heavy resource use and costly maintenance.

Let’s examine what the standalone architecture looks like:

When using this architecture, you can get the following advantages:

• Full isolation and independence for every tenant at the application level
• Opportunity for independent customizations like adding new features for each tenant
• Scalability for each tenant depending on their size, load, and number of users
• Elimination of the noisy neighbor effect, as only chosen infrastructure and a tenant’s own users can affect the tenant’s work
• Easy and quick development thanks to fully independent applications for customers. In this scenario, developers don’t need to implement functionality to manage each tenant individually as they have to ensure in the multi-tenant model, where the application level is shared between several tenants.

However, when working with a single-tenant model, you need to know that:

• Full isolation doesn’t allow you to distribute shared resources between tenants. Each tenant works with their own database, application, and services, which leads to high costs for environment use.
• Your development team will spend much time updating each instance and creating a new environment for a new customer. On the bright side, your developers can use a few automation options like the Infrastructure as Code (IaC) approach.

When should you use the single-tenant model?

This model is a perfect choice if your customers require full isolation. Such data isolation can help your customers minimize security risks and demonstrate ongoing compliance with various requirements and SaaS data security standards. Also, consider using the single-tenant approach if you need to quickly start developing your SaaS project and your product isn’t supposed to have hundreds of tenants as soon as it’s delivered. Moreover, this model can simplify scaling processes, as you have more computing capacity and on-demand resources to get the job done fast.

2. Multi-tenant models: pros and cons

In the multi-tenant model, also called one to many, application resources (along with resources like software instances, databases, and cloud or hardware resources) are shared among several customers.

With this approach, you as a SaaS provider can lower the environment and infrastructure costs for customers as well as simplify integration and maintenance work. However, the multi-tenant model leads to possible gaps in data security, complicated product updates, and weak customization capabilities.

The multi-tenant model offers three ways to distribute tenants between databases depending on how data will be isolated.

Let’s take a closer look at each model, exploring its pros, cons, and use cases.

Database-per-tenant

The main advantage of this multi-tenant model is that data of each tenant is isolated and stored in a separate database.

Note: When working with separate databases, you don’t need to have dedicated hardware with the installed database server. Instead, you can use cloud services like Azure SQL database, Elastic Pool, and Azure SQL Managed Instance, which can help your team save money and time on configuring, supporting, and scaling your environment.

The database-per-tenant model ensures:

• Data isolation at the database level for each tenant
• Opportunity to scale database resources for the needs of each tenant: data storage volume, load, etc.
• No risk of the noisy neighbor effect at the database level, though it can still appear at the application level.

Note: As all tenants share the same application level, the noisy neighbor effect can now appear. But in such a case, this issue isn’t caused by the data volume of separate tenants but by the number of requests to the application. If some tenants cause a significant load increase, your team can easily scale the application level using one or several instances located in the load balancer.

However, the database-per-tenant model isn’t easy to implement. For example, this model requires your team to:

• Create additional logic for forming requests for each database. To make that happen, your developers need to use the Catalog database, which stores all of the tenants’ relations with relevant databases.
• Provide simultaneous updates of databases and applications and continuous support for backward compatibility.
• Put much effort into customizing the business logic level, as this level is shared between all tenants.

When should you use the database-per-tenant model?

The database-per-tenant model is a great option when you need to ensure a sufficient level of data isolation for your customers while also reducing the costs for deploying your SaaS product.

Sharded database

In this multi-tenant model, one database is shared between several tenants.

To implement this approach, you need to provide each table with an additional tenant key, which makes sure that the current tenant can receive data only with the corresponding tenant key. You can create the logic for receiving the required data for a tenant:

• At the application level by adding a tenant ID check
• At the database level by configuring the sharding pattern or row-level security, which ensures the efficient work of the tenant’s application with already isolated data, increasing data isolation

The sharded database model offers:

• Decreased environment costs thanks to the opportunity to combine several tenants in one database
• High scalability and simplified database management thanks to distributing tenants across several small databases

Meanwhile, this multi-tenant database model might cause:

• Weak data isolation between tenants, as their data is stored in a single database
• Lengthy logic development for tenants to receive data, as your engineers need to work on tenant data isolation and security
• The noisy neighbor effect at the database level

When should you use the sharded database model?

The sharded database model is a great choice if your SaaS system targets small customers, as you can ensure decent data security, application performance, and scalability. However, you shouldn’t use this approach if your SaaS product targets customers that regularly store and process lots of data.

Note: As common resources are shared by multiple tenants, the most active and voluminous tenant might affect the work of others. To solve this issue, your developers can provide this tenant with an independent database server. But keep in mind that to timely detect and fix the noisy neighbor issue, your team should establish efficient system monitoring in the first place.

By providing one or several tenants with independent database servers as proposed above, you shift your multi-tenant model from sharded to hybrid. Let’s take a closer look at it in the next section.

Hybrid

A hybrid model is a compromise that combines characteristics of the database-per-tenant and sharded database models. With this approach, your team can completely isolate a noisy neighbor from other tenants, or provide a customer with separate resources according to their cybersecurity-related request.

The hybrid model offers logic that allows you to move a tenant’s data from one server to another. To create such functionality, each database should contain a tenant’s ID in its scheme. You can define how many tenants will be stored in one database depending on your SaaS system’s specifics. In general, the hybrid model is a sharded database model, but with the ability to provide a single tenant with a private database upon request.

The ability to move tenants between different databases is a key advantage of the hybrid model. Tenant data isolation and security will be assured by the application, but it can be enhanced by moving the tenant into a separate database if needed.

The hybrid approach has the same advantages and disadvantages as:

• Database-per-tenant option if a tenant has a separate database
• Sharded database model if several tenants use the same database

When should you use the hybrid model?

The hybrid model is a great option for a SaaS product that’s built for tenants of different sizes, as your team can place smaller customers within a single database and create dedicated databases for larger ones.

If you’re planning to create a SaaS product but aren’t sure which database model to choose, Apriorit’s SaaS developers will help you pick the most suitable option to meet your business and cybersecurity goals.

Ensuring secure storage for sensitive data

Even when choosing the most suitable database model, you can’t guarantee your tenants flawless user data protection. Establishing a solid base for your customers’ data security requires your team to do more, including securing data storage.

Depending on your customers’ locations and lines of work, you have to help them ensure that data handling operations meet applicable cybersecurity laws, requirements, and standards. For example, well-known personally identifiable information (PII), payment card industry (PCI), personal health information (PHI) policies, and the GDPR regulate that users’ personal data can’t be openly stored in applications and databases.

So, how can you secure user data to help your customers comply with different requirements? Here are a few popular ways:

1. Hashing is a reliable data protection method based on storing hashes instead of real data. As the hash function is a one-way function, sensitive information won’t be compromised even in case of a data leak, as criminals won’t be able to get the original values.

Hashing is usually used to secure data like passwords, and here’s how it works:

1. A user types in their password during registration.
2. The system generates a hash of this password and saves it to a database.
3. When entering the system, the user types in their password again.
4. The system generates a hash of the entered password and compares it to the hash saved in the database.
5. If the values match, the system grants the user access.

This way, you don’t store a password in the system openly but can check for password correctness during login.

2. Tokenization is the process of substituting data for an identifier (a token) that represents this data in a tokenization system. Tokenization is commonly used for payment cards (credit card numbers, bank accounts) substitution. This way, your SaaS product won’t store sensitive information, and all services that request such data will receive it from a third-party system (called a tokenizer).

A tokenizer usually offers options such as making a token’s form identical to the original form of what it represents and providing the ability to store a part of the original value in a token. This can be convenient for sensitive data that needs to be shown often in an application, like a social security number in healthcare solutions.

3. Encryption with a reliable algorithm like RSA is a great way to enhance the protection of stored data. You can implement this method at the application level to encrypt data when adding it to or receiving it from a database. Another option to ensure encryption is database functions. For example, MS SQL Server offers the Always Encrypted function that allows you to automate the encryption of certain columns.

4.  Secure storage like Azure Key Vault and AWS Key Management Service are a great way to store credentials and encryption keys. You can provide access to such secure storage, for example, only to a tenant’s application, inside the virtual network, or for a certain IP.

When working with each of the listed ways to secure sensitive data, it’s essential to keep in mind some existing limitations and nuances:

• Multiple cybersecurity methods. Each data type might require a different protection method, so your SaaS system must offer several ways to secure tenants’ sensitive data in storage.
• Need for extra resources. Any action on data requires system resources and time for request execution.
• Search limitations. Searching modified data is either impossible or significantly complicated.

To discover more details about ensuring the secure storage of sensitive data and enhancing the protection of both on-premises and cloud environments, check out our Cloud-Based Application Development: Data Security and IT Compliance Challenges article. Learn how to demonstrate compliance with the GDPR, NIST, PCI DSS, ISO/IEC 27001, and other regulations, standards, and laws.

Securing data during product maintenance

Any SaaS solution requires maintenance from development and support teams after software delivery. Thus, you can ensure your product has everything it needs to run flawlessly.

During the support and maintenance stage, your team should:

• Keep an eye on server and database management, making sure everything works securely and efficiently
• Establish thoughtful infrastructure monitoring and sufficient system logging
• Keep user data secured

The last task can be hard to accomplish because when supporting a SaaS system, developers need to investigate incidents and issues that happen to user data. Thus, it’s essential to make sure that when doing so, your engineers don’t harm or compromise sensitive information.

From Apriorit’s experience, there are two crucial things to pay attention to:

1. Protect sensitive data in logs

The more details your solution’s logs contain, the more helpful the logs are in case any issues arise. However, like databases, logs shouldn’t contain sensitive data. Sensitive data must be either removed from log messages or masked.

One option to ensure this is to use the Serilog library. It provides many useful opportunities including:

• A wide choice of connections (sinks) to different storages to which logs will be added
• The ability to enrich log events with properties using different enricher packages
• The possibility to hide sensitive data like emails and bank accounts using the Serilog.Enrichers.Sensitive extension with an opportunity to create custom hides

2. Secure the developer’s work with user data

To secure some vulnerabilities, your team may need to reproduce a potential threat or problem on user data, but without providing developers with access to the actual data and data backups.

What you can do is grant developers access to a copy of the customer’s database in which all sensitive user data is masked. To ensure that, your team needs to come up with a service that will provide developers with a database backup of a certain tenant for a specified period with all sensitive data masked upon a developer’s request.

To make the developer’s work convenient and efficient, it’s essential to save existing field types when masking data. For example, you can:

• Substitute email addresses with a default myappuseremail{userId}@myapp{userId}.com
• Substitute usernames with UserName{userId}, where {userId} is a real user identifier in the system
• Substitute non-unique fields whose contents are only informative with a constant value like comment

This way, when investigating incidents developers can act on data of a user who has experienced issues without actually seeing their sensitive data. By doing this, you’ll eliminate the risk of developers unintentionally harming data.

Conclusion

Providing robust data protection in SaaS products starts with choosing the database structure that best fits your software business model and your customers’ security requirements.

While the single-tenant approach offers maximum data isolation, it might lead to poor scalability opportunities in the future and expensive software maintenance in the long run. Meanwhile, database-per-tenant or hybrid approaches might be better in terms of scalability and costs. Even when you place several tenants in a single database, there are ways to achieve decent data isolation from other tenants for a reasonable price.

However, it’s not only the database structure that affects data security in SaaS systems. Your development team also needs to establish strong protection of sensitive data and the application itself using various encryption methods, tokenization services, reliable third-party storage services, and proven ways to secure data in logs and databases for developers’ work. All these activities can create a solid basis for SaaS product cybersecurity.

At Apriorit, we have vast experience delivering efficient software for industries including healthcare, logistics, real estate, accounting, and HR. Apriorit’s professional SaaS development team delivers all projects with a strong focus on cybersecurity.