A TALON.

ONE EBOOK

Intro to
SaaS Security
& Architecture
‘‘
In 2021 the SaaS market is expected
to reach a valuation of $272.49 billion,
and it’s growing around 20% each year.”
The Business Research Company

Security should be a fundamen- This ebook offers an overview

tal consideration when selecting
SaaS platforms for your business.
The more secure your software
stack, the better you can protect
your customers’ data and your
business itself.
of the essentials of SaaS secu-
rity, provides tips to help you im-
prove security across your soft-
ware stack, and explains some of
the security features built into our
own product.

What’s inside?
Understanding SaaS architecture 3

Security considerations for SaaS platforms 4

Factors to consider as an SaaS customer 6

Single-tenant vs. Multi-tenant systems 7

API Security 8

Security in headless stacks 9

Talon.One’s architecture and security credentials 10

Talon.One • Intro to SaaS Security & Architecture 2

Understanding
SaaS architecture
SaaS software systems are fundamentally different from conventional
business software platforms in their underlying architecture.

Enterprise software companies increasingly

use the SaaS delivery model because of the
wide-ranging benefits it offers over conven-
tional, on-site systems:

• Reduced setup and operation costs
for the customer
• Increased scalability as business
demands grow
• Increased customizability and flexibility
for individual business use cases
• Reduced integration time/go-live delay —
quicker to feel the benefit
• Easier to deploy, update and maintain
These benefits are a direct result of SaaS soft-
ware architecture. In its simplest form it con-
sists of two layers:
• The database layer (servers that store client
and end-user data)
• The application layer (nodes/servers that
host the application frontend and backend)
On top of these two layers sits the delivery
layer, which is where the software and func-
tions meet the user (e.g. an app or web page).
SaaS architecture can vary signifi-
cantly between platforms. Some
have additional components, like
nodes in the database layer which
can help with scaling or data sepa-
ration in a shared client database.
The structure of the application and
database layers can also vary signifi-
cantly. This depends on the functions
of the service and any third-party
platforms it interacts with.
Generally these are
considerations for SaaS
providers themselves.
But it’s good to have
a basic understanding
of SaaS architecture to
inform your understanding
of SaaS security.

Talon.One • Intro to SaaS Security & Architecture 3

Security considerations
for SaaS platforms
The SaaS industry as a whole has numerous accepted conventions
and best practices that ensure SaaS performance and security.

Below are some key industry-standard security principles for SaaS platforms:

Data in transit protection

Data sent between a web application
and a client, or between SaaS micro-
services (data in transit) is vulnerable
unless secured. The standard proto-
col for encrypting data in transit is
Transport Layer Security version 1.3
(TLS 1.3). It’s responsible for secur-
ing HTTPS communications and it’s
essential for all SaaS platforms and
web applications.
Multi-factor
authentication
Multi-factor authentication helps
protect against brute force at-
tacks and third-party data theft.
It does this by requiring users to
provide two forms of identity veri-
fication when logging in.

Talon.One • Intro to SaaS Security & Architecture 4

 Detailed activity,
security and event logs
Detailed logs help establish clear trails of ac-
countability among users and other stakehold-
ers. They’re an essential tool for analyzing securi-
ty breaches and other cases of software misuse.

Privilege separation
SaaS platforms should employ a
hierarchy of privilege/privilege sep-
aration for user accounts, applica-
tions, API clients, etc. This ensures
that each user or component in a
system only receives the minimum
software functions or permissions
needed to do their job. An example
would be standard user accounts
lacking editing privileges.

Without privilege separation, un-

authorized users may be able to
access sensitive data and exploit
software for malicious purposes.
Proactive patching
SaaS providers should have a priority software
patching process in place to respond to security
breaches and other incidents. The quicker the re-
sponse time, the easier it is to mitigate potential
damage. Regular software updates are another
essential practice for application security.

Talon.One • Intro to SaaS Security & Architecture 5

Factors to consider
as an SaaS customer
Clarify your minimum business and security requirements
with the provider before signing.

Depending on the jurisdictions in which you operate, you’ll need to pick

an SaaS provider that meets certain specifications.

Common security certifications/frameworks include:

For example, many countries require SaaS providers to store cus-

tomer data within their own borders. If your SaaS provider doesn’t
follow these rules, you could find yourself liable.

It’s also important to establish your security and

service expectations with providers before you sign
a contract. It should include clauses to cover service
disruptions, data theft, software capabilities, etc.

Anything that falls outside the scope of work in your contract likely
won’t be covered in the event of disruption or software failure.

Talon.One • Intro to SaaS Security & Architecture 6

Single-tenant vs.
Multi-tenant systems
There are some important distinctions between single-tenant and
multi-tenant SaaS systems that can have implications for system security.

Single-tenant systems Multi-tenant systems

Single-tenant systems provide each cus-
tomer with an independent database
and software instances. This provides
many benefits:
• Dedicated resources for each customer
so that performance isn’t impacted by
other customers’ demands
By comparison, multi-tenant systems al-
locate multiple customers to shared data-
bases and application instances, making
them cheaper to maintain and manage.
But they’re less secure than single-tenant
systems because they use logical rather
than physical data isolation.

• Increased security as each customer’s When considering a multi-

data is physically isolated from others tenant only SaaS provider,
• Application features and setups can be check which processes they
customized for individual customers have in place for data isolation
and resource allocation.

Client A database Client B database Client A database Shared database

Client A application Client B application Common application for all users

Client Client Client Client Client

A B A B C

Talon.One • Intro to SaaS Security & Architecture 7

API Security
APIs form the backbone of all SaaS applications and headless
software stacks. As such, they’ve become a key target for attacks.

Gartner predicts that by 2022 APIs

will be the most frequent attack vector
against enterprise web applications.

Open/public APIs are more vulnerable because they’re Input validation

exposed to public systems. Here are some essential All inputs should be validated
considerations and best practices for API security: before passing to the API. This
ensures that data is formatted
correctly, reducing the likelihood
of errors. It also helps mitigate a
Authentication and authorization variety of attacks, including SQL
API authentication helps secure data as it’s transferred
Injection and cross-site scripting.
to and from APIs. They provide authorization tokens to
verify the identity of applications interacting with an API.
Validation should always
Open source, third-party mechanisms like 0Auth 2.0 and be mirrored on the client
OpenID Connect are popular because they’re secure and
and server sides to ensure
easy to implement. Both are built using the OpenAPI
framework, a tried and tested open-source system that client-side validation
that’s used by SaaS providers across the industry. hasn’t been bypassed.

Rate limiting
Rate limiting limits the rate at which API requests can HTTPS and SSL
be made, helping protect against distributed denial of certified servers
service (DDoS) attacks. APIs should always connect via
HTTPS/SSL certified servers.
Without it there’s no way of
Ensure any API you use,
knowing whether data passing
either internally or externally has from the browser to the API is
a rate-limiting system in place. actually encrypted.

Talon.One • Intro to SaaS Security & Architecture 8

Security in
headless stacks
The headless model is now prevalent in all corners of the SaaS industry.

Headless applications function Your headless stack is only as strong

without a frontend delivery layer,
as its weakest link. Ensure that
and are designed to be integrated
with one another via API. Together every microservice and additional
they form bespoke stacks which component within meets your
can cater to any business cus-
minimum security requirements.
tomer’s requirements.

Don’t use non-maintained Headless commerce stack

applications
Many businesses may be running Frontend
older versions of critical pieces of
software unknowingly. Out-of-
date applications can pose a sig-
nificant security risk to the rest
of your software stack, so make
sure you’re aware of each appli- Promotions Payments

cation version’s lifespan.

MICROSERVICES

Configuration files
Never leave sensitive information Customer Experience Customer Data
like passwords, authorization to- Platform Platform

kens, or private keys in configura-

tion files. If necessary, passwords
can be stored in a separate en-
crypted file.
Customer Support Inventory

Talon.One • Intro to SaaS Security & Architecture 9

Talon.One’s architecture
and security credentials
Talon.One is built on Kubernetes, an open-source platform
for cloud-based applications which automates deployment,
scaling and management.

Kubernetes uses clusters, or sets of nodes (machines),

to run containerized applications and allows numer-
ous instances of an application to be run across mul-
tiple different machines in a cluster.

We offer a single-tenant platform

Kubernetes allows us to Each cluster runs automat- We offer demo environ-

offer each customer indi-
vidual deployments. Each
deployment extends across
two different Google Cloud
availability zones, with a
synchronized master and
at least one deployment in
each zone.
Why? To minimize service
response times in all time
zones.
ic hardware and software ments for our customers to
health checks. test campaigns before going
live. We also have a test en-
Why? So we can isolate vironment for our own appli-
and replace faulty cation updates. Prospective
components to maximize customer data (from demo
reliability and minimize accounts) is stored on a
downtime. shared database with logi-
cal data isolation.
Why? Demo and test
environments allow us and
our customers to iron out
issues before going live.

Talon.One • Intro to SaaS Security & Architecture 10

 We log all changes made in Talon.One

Customers can view all changes made in Talon.One via

the Audit Logs menu. This includes campaign updates
and any changes to user permissions and roles.

Why? Activity logs are an essential tool that help

protect customer and user data from unauthorized
access and tampering. They also help us improve our
troubleshooting processes.

Our databases are run by Aiven

on Google Cloud

Both Aiven and Google Cloud are ISO27001 and SOC2

compliant. Each database has a standby copy locat-
ed in a second availability zone with automatic hando-
ver in case of catastrophic failure. We have a separate
backup mechanism that allows us to restore data from
any point in the past seven days.

Why? Customers can use our service even

in the event of database failure, and can choose
their backup point from the past week.

We allow IP whitelisting

We offer IP whitelisting so customers can build a list of

trusted domains that can send data to their deployment.

Why? Whitelisting provides control over who has

access to deployment and where it can be accessed
from. Our customers often use the feature to secure
the .CSV file upload process, which is frequently used
in referral and coupon campaigns.

Talon.One • Intro to SaaS Security & Architecture 11

Vulnerability/penetration tests Infrastructure tooling
only accessible via VPN
We contract a third-party company to carry out frequent
penetration and vulnerability tests on our system. All of our infrastructure and de-
ployment tooling, clusters and
Why? It allows us to identify and patch any security internal databases are stored
exploits as soon as they are discovered. This helps us inside our own private cluster
protect our infrastructure and customer data. and only accessible via VPN.

Third-party penetration testing is essential because Why? This seals our vital
it allows us to understand how malicious individuals infrastructure within a tightly
or organizations would approach our system. controlled internal environment
We can then review and fix any vulnerabilities that’s otherwise inaccessible
uncovered in the testing process. without our approval.

Updates

We follow CI/CD (continuous integration/continuous de-

ployment) processes for all system components and de-
pendencies, including PostgresQL and Kubernetes cloud.

Why? Always-up-to-date systems ensure maximum

performance for our customers and maximum
protection against data breaches and attacks.

Talon.One • Intro to SaaS Security & Architecture 12

 The World’s Most Powerful Promotion Engine
Create and deploy creative and targeted campaigns
using any of your customer and live session data.

MAKE YOUR PROMOTIONS POSSIBLE

promotions@talon.one

BOOK YOUR FREE DEMO

talon.one/book-a-demo