Architecting Layered Security in a Cloud Data Warehouse

Introduction

In an era where data breaches and unauthorized access are daily headlines,
organizations face challenges in safeguarding their data. Building a robust security
model is essential to protecting and safeguarding data and other core digital
assets that organizations own. This is becoming even more critical as organizations
adopt and embrace cloud-based solutions and deployments.The responsibility for
securing the infrastructure and the SaaS service rests with the service provider,
while customer-managed controls enhance data and access security.

At Firebolt, we are committed to the security of our platform and our customers’
data and privacy. As such, we designed our service to keep customer data secure
and always protected. We have developed state-of-the-art privacy and security
systems, policies, and practices in accordance with known industry standards,
compliance, and regulatory requirements. Furthermore, we offer rich security
mechanisms that allow Firebolt users with tools to safe and secure deployments for
applications built on top of Firebolt.

In this blog, we will introduce and explore Firebolt’s foundational security
elements that are available to Firebolt users. Firebolt secures customer data using
a defense-in-depth model with multiple security layers. We will explore this layered
security methodology starting with network and protocol level security, through
identity management and access control, and all the way to data level protection.

Firebolt provides functionality to establish a robust security foundation that ensures
your data remains not just secure, but also compliant and efficiently accessible.
Let’s dive in.

Infrastructure and
Network security

Transport Layer Security (TLS) is a cryptographic protocol designed to provide
communications security over a computer network. It is a widely adopted security
protocol designed to facilitate privacy and data security for communications over
the Internet. TLS is particularly important for transmitting sensitive information such
as login credentials, financial data, personal information, and other confidential
information. It also verifies that the data has not been forged or tampered with. As
such, TLS intends to keep the data secure when data is being transferred over a
network, protecting it from eavesdropping and session hijacking. Firebolt ensures
end-to-end encryption using TLS safeguarding data transmission from end users to
our cloud service.

Note: TLS 1.2 is the minimum compatibility level that is supported by Firebolt

In addition to the TLS protocol mentioned above, Firebolt supports defining
custom Networks Policies. Network policies add an extra layer of security to
an application. This functionality allows administrators fine-grain control that
governs IP ranges that are allowed to access Firebolt. With network policies, one
can reduce the risk of unauthorized access and potential security breaches by
allowing access only from specified IP addresses or defined network ranges. Once
created, a network policy can be attached to an organization or to an individual
login and/or service account. Furthermore, network policies are hierarchical in
nature. Organization level policies can be defined as policies that come with wider
IP ranges compared to the policies that are attached to the logins and service
accounts giving administrators and various security policy owners finer security
control and protection.

Note: Firebolt supports a LOGIN object to represent a given security principal
(human) defined by an email address, while SERVICE_ACCOUNT object is used to
represent a machine that will authenticate itself to the system.

  • Segmentation and micro-segmentation: Network policies can facilitate
    network segmentation and isolation, separating different components or
    services of your SaaS application into distinct network zones. This helps contain
    potential breaches or attacks, limiting their impact to a specific segment and
    preventing lateral movement within the network.
  • Reduced risk of account takeover: IP allow lists and network policies can help
    protect against account takeover attacks. Even if an attacker manages to obtain
    valid user credentials, they will be unable to access the SaaS application if their
    IP address or network is not on the allowlist.
  • Mitigation of unauthorized access attempts: Implementing network policies
    helps prevent unauthorized access attempts by blocking requests from
    unauthorized IP addresses or networks.

Example:
Let’s see the network policy in action. In Firebolt, network policy objects contain
allowed_IP_list and blocked_IP_list properties that capture definition of IP address
ranges. Each property is a list and can contain one or more IP ranges.

To create a network policy, use:

1CREATE NETWORK POLICY IF NOT EXISTS my_acme_np WITH
2ALLOWED_IP_LIST = (‘44.224.89.1/24’)
3BLOCKED_IP_LIST = (‘44.224.89.3’)
4DESCRIPTION =new network policy for my acme organization’;
5CREATE NETWORK POLICY IF NOT EXISTS kate_np WITH
6ALLOWED_IP_LIST = (‘44.224.89.7’)
7DESCRIPTION = ‘Kate’s network policy’;

To apply a network policy to the organization or individual login, use:

ALTER ORGANIZATION acme SET NETWORK_POLICY = my_acme_np;
ALTER LOGIN “kate@acme.com” SET NETWORK_POLICY = kate_np;

Identity management
(authentication)

Identity management is a multi-step verification process that is used to confirm
that only the right people, services, and apps can get access to the organizational
resources. Identity management includes user identification and authentication.
During the identification phase, users establish who they are typically by providing
a username. During the authentication step, users need to prove they are who
they say they are by entering a password (something only the user is supposed
to know). To strengthen security, many organizations also require Multi-Factor
Authentication (MFA) as an additional security measure. It will requires users to
provide two or more forms of identification before they can access a system or an
application

Firebolt supports an effective authentication process by offering administrators
to manage usernames and passwords within Firebolt environments and via the
existence of the LOGIN object. We use Auth0 as the identity provider for customer
registration, and the authentication data is stored in Auth0 using industry-standard
cryptography. Authentication information is exchanged using SAML 2.0 protocol.

Single Sign-On (SSO)

Many organizations have already implemented identity management by
leveraging 3rd party identity providers and solutions. To simplify and streamline
implementation, to enhance security posture and fortify defense against
unauthorized access and data breaches, Firebolt also supports Single Sign-On
(SSO). SSO simplifies the user authentication process and enhances security by
allowing users to access multiple applications and services using a single set of
credentials.

At Firebolt, SSO configuration is available to all members of org_account built-in
role. This option is simply configured by navigating to the Configure space within
Firebolt Workspace (picture shown below).

We recommend enabling SSO for the following reasons/benefits:

  • Enhanced user experience: SSO reduces the need for users to remember
    multiple usernames and passwords, simplifying their login experience and
    improving productivity.
  • Streamlined implementation: SSO can be seamlessly integrated with popular
    identity providers like Okta, Salesforce, and others while leveraging their robust
    authentication protocols.
  • Secure authentication protocols: Implementing strong authentication
    protocols such as SAML (Security Assertion Markup Language) or OAuth
    (Open Authorization) is essential to ensure the integrity and confidentiality
    of user credentials during the authentication process.

Multi-Factor Authentication (MFA)

Multi-factor Authentication (MFA) adds an extra layer of security by requiring users
to provide multiple forms of authentication to access an account. Many industries
have specific compliance and regulatory requirements that mandate the use of MFA
for certain types of data or systems – Firebolt fully supports these requirements
with MFA configuration and implementation that is tied to the LOGIN object.

Note: In Firebolt, org_admin built-in role (and any grantee of such role) can
enable/disable MFA configuration for different logins. Once MFA is enabled for
a given login, the principal behind that login receives an email with additional
instructions that allows MFA to be configured. Firebolt leverages Okta for common
organizational service access. Through both Auth0 and Okta, we enable SSO, MFA,
password complexity, and expiration policies in a centralized manner.

Example:
Below examples demonstrates creating a login with first and last names, no
predefined network policy as well as enabled MFA configurations:

CREATE LOGIN “kate@acme.com” WITH
FIRST_NAME = ‘Kate’
LAST_NAME = ‘Peterson’
IS_PASSWORD_ENABLED = TRUE
IS_MFA_ENABLED = TRUE;

Access control (authorization)

Once the user is authenticated, the next step in the security chain is access control
(authorization). Authorization ensures that the user has appropriate permissions
to access the system or system level resources it attempts to use. At Firebolt, we
implemented Role Based Access Control (RBAC) mechanisms for these purposes.

We designed our RBAC model with the following principles in mind:

  1. Any object in the Firebolt object model is a securable.
  2. Any supported statement is guarded by a permission (no unauthorized actions).
  3. RBAC model is composable (effective permissions are the sum of role assignments).
  4. Roles are hierarchical and can come with inheritance relationships.

Key building blocks/concepts of the Firebolt RBAC model are: users, roles, objects/
securables and permissions. Let’s explore these concepts more in the sections

Roles:
There are 2 types of roles that exist within Firebolt:

  1. built-in roles that are available as soon as new organization and the first account get provisioned, and
  2. user-defined roles that administrators can create by themselves.

We have carefully designed a set of predefined roles that align with common user personas and responsibilities. Each built-in role is associated with a specific set of permissions tailored to the tasks and activities relevant to the role. Predefined roles include org_admin, account_admin, system_admin, security_admin and public.

Role Name Description

public

Allows working with public schema in any database in the account.

system_admin

Enables managing databases, engines, schemas, tables, views, external tables, and grants, as well as setting database and engine properties. In addition, the system_admin role enables access to the observability functionality on all engines.

account_admin

Enables all the privileges of the system_admin and security_admin roles alongside the ability to manage the account.

org_admin

Enables global privileges across the entire organization. Allows for onboarding authentication objects (logins, service accounts, single sign-on), network policies and multi-factor authentication.

In addition to built-in roles, custom or user-defined roles can be created as well.
Creating a role is simple and can be done using the Firebolt UI or via SQL (for actual
dialect, reference Firebolt documentation).

Note: While built-in roles already have a pre-built set of permissions assigned,
user-defined roles can be subject to permission assignment (by using grant/revoke
statements).

Securables and permissions:

Permissions define the actions or operations that can be performed within Firebolt.
These permissions range from managing databases and engines to executing
queries and accessing and analyzing data. Each instance of an object (securable)
in the Firebolt object model has specific permissions that are associated with it. As
an example, there could be multiple instances of an engine object (i.e. my_engine1,
my_engine2) and each instance comes with a set of predefined permissions. 

We will avoid documenting here all permissions that are available for each object in
our object model. For illustration purposes, picture below enumerates permissions
tied to the account, database and engine objects.

Note: for a full list of available permissions, please reference our user
documentation.

Any permissions that Firebolt supports can be granted/revoked to/from the role(s).
Grant is a process of associating various permissions to a given role(s). In contrast,
revoke is a process of removing a given permission or set of permissions from a
role. Firebolt supports standard SQL constructs (GRANT and REVOKE) to support
permission assignment processes.

Example:

CREATE USER kate; -- create user kate
GRANT ROLE sales TO USER kate; -- grants sales role to user kate
REVOKE ROLE sales FROM USER bob; -- revokes sales role from user bob
ALTER USER kate SET LOGIN = “kate@acme.com”; -- establishes a link between a login and a user which grants ability for kate@acme.com principal to connect to account dev_account

The RBAC model described above provides lots of flexibility to implement a finegrained
and granular security model to fit advanced security protection and needs.
While the model offers such granularity and flexibility, with built-in roles Firebolt
also provides simple and out of the box solutions that can be used for basic
implementation and scenarios. Consider using either or both models based on your
security requirements and needs.

Data protection

Firebolt is firmly committed to data security, privacy, and compliance. To deliver
on that promise, Firebolt ensures that all data managed by Firebolt is properly
safeguarded and protected. Firebolt policy mandates the enforcement and
governance of encryption standards for data in motion and at rest. The following
functionality is available for our customers automatically and out of the box.

Data at Rest Protection:

Encrypting data at rest ensures that even if physical storage media is stolen, the
data remains unreadable without the appropriate decryption keys. By default, we
encrypt all data at rest leveraging industry-standard encryption algorithms. Key
management is performed through a robust encryption key management system to
securely generate, store, rotate, and retire encryption keys. Secure transmission of
encryption keys from the key management system to the encryption or decryption
components is performed to prevent interception or tampering. Additionally,
controls at the data layer enforce authorized access to users and applications.
Audit and monitoring mechanisms are used to track and log access to encrypted
data and encryption key management activities. Firebolt also implements secure
data deletion practices to ensure that data is properly wiped or destroyed when no
longer needed.

Data in Motion Protection:

Encrypting data as it travels over networks ensures that it’s secure and cannot
be intercepted by eavesdroppers. Firebolt automatically encrypts sensitive data
that is being transferred/sent within service components by implementing TLS for
secure communication between the client and server. TLS ensures both parties
authenticate each other using digital certificates, providing an extra layer of
security against man-in-the-middle attacks. Firebolt uses strong and secure cipher
suites in TLS configurations.

Summary

Firebolt remains dedicated to providing our customers with a secure and trusted
Cloud Data Warehouse as a Service platform for their modern enterprise needs.
With capabilities mentioned in this document combined with controls we employ
on infrastructure, application, and PII security, Firebolt customers can achieve:

  • Defense in Depth: First and foremost, Firebolt’s approach to managing data
    assets through the use of accounts provides boundaries to isolate and secure
    data assets. Additionally, with advanced security features and industry best
    practices, Firebolt ensures your data remains secure, compliant, and accessible
    only to authorized individuals through a layered security approach. This holistic
    approach leverages various capabilities such as data-at-rest-encryption,
    multi-factor authentication and single-sign-on integration, role-based access
    control and network policies to secure data assets in your data warehouse.
  • Reduced Surface Attack: By using functionality mentioned in this document,
    you can significantly reduce the potential attack surface, making it harder for
    adversaries to exploit weaknesses.
  • Compliance and Regulatory Adherence: Delivering on various industry-specific
    standards and regulations is a non-trivial task. Firebolt adheres to industry standards and certifications, such as GDPR, SOC2 Type 2, ensuring businesses
    can meet their regulatory requirements while taking advantage of the efficiency
    and flexibility of our Cloud Data Warehouse service.

In the evolving landscape of cloud-based solutions, it’s imperative to recognize
that security is a shared responsibility. While Firebolt offers advanced features
and safeguards to ensure data security, customers must also play an active role
in securing their data. This collaborative approach entails Firebolt managing and
securing the underlying infrastructure, while customers must implement best
practices in data governance, access controls, and application security. By working
in tandem, one can establish a robust and resilient security posture, ensuring that
data assets remain protected in an ever-changing digital environment.

Contact Firebolt

For more information about Firebolt

Contact us
Send me as pdf