Network security
Firebolt ensures secure data transmission by implementing end-to-end encryption with Transport Layer Security (TLS) version 1.2, protecting data as it moves between end users and the cloud service. Firebolt supports the creation of custom network policies, adding an extra layer of security to your applications. This functionality allows administrators to exercise fine-grained control over which IP ranges can access Firebolt. In Firebolt, network policies containallowed_IP_list
and blocked_IP_list
properties that capture definition of IP address ranges. Each property is a list that can contain one or more IP ranges.
Firebolt supports individual and programmatic access through the following:
- Login - A login object represents an individual user, identified by an email address, who will authenticate by verifying their identity to access Firebolt.
- Service account - A service account object is used to represent a machine or application that will authenticate and interact with Firebolt without human intervention.
my_network_policy
with a description that allows only two IP addresses:
my_network_policy
to my_organization
and to the login associated with kate@acme.com
, which restricts access according to the rules of that policy:
Identity management
Identity management is a multi-step verification process designed to ensure that only authorized individuals, services, and applications can access organizational resources. Identity management involves both identifying users and verifying their identity through authentication. Firebolt uses Auth0 as its identity provider for managing customer registration. All authentication data stored in Auth0 is protected with industry-standard cryptography. Authentication information is securely exchanged using the SAML 2.0 protocol. Firebolt provides the SSO and MFA authentication methods.Single sign-On (SSO)
Single Sign-On (SSO) is an authentication method that allows users to access multiple applications or services using a single set of login credentials, simplifying the authentication process and improving security through centralized identity management. Firebolt uses SSO to simplify and streamline implementation of secure access to its platform, enhancing the overall security posture and protecting against unauthorized access and data breaches. SSO configuration is accessible to users with theorg_account
built-in role.
Multi-factor authentication (MFA)
MFA strengthens security by requiring users to provide multiple forms of authentication to access their accounts. Many industries have compliance and regulatory standards that require the use of MFA for securing certain types of data and systems. Firebolt fully supports these standards by offering MFA configuration and implementation directly linked to the login object, ensuring secure and compliant access control. Example The following code example creates a login for a user, enables password-based authentication, and requires MFA to authenticate:Access control
Access control ensures that users have the necessary and appropriate permissions to engage with Firebolt’s system or resources. Firebolt implements role-based access control (RBAC) to manage permissions. The RBAC model is centered around the following principles:- All objects can be secured.
- Every supported statement requires explicit permission, preventing unauthorized actions.
- The RBAC model is composable, which means that a user’s total permissions are the result of combining all the roles assigned to them, giving them the collective access granted by each role.
- Roles are hierarchical and allow permissions to be inherited through role relationships.
Roles
A role is a set of permissions assigned to a user or group that defines what actions they are authorized to perform and what resources they can access within Firebolt. Firebolt has the following types of roles:- Built-in roles have a set of pre-defined permissions and custom user-defined roles that can allow for more specific use cases. You can use GRANT and REVOKE statements to modify permissions for custom roles. Built-in roles become available as soon as a new organization is created, and the first account is set up.
- User-defined roles are custom roles that administrators can create to grant a specific set of permissions.
-
System-defined roles align with common user personas and responsibilities including
public
, which is granted to each new user by default, asystem_admin
role, and anaccount_admin
role. For more information about these roles, see System-defined roles.
sales
, which can later be assigned specific permissions and granted to users to inherit those permissions:
Users
Users are linked to either a login or service account in order to gain access to Firebolt. They can be created using the CREATE USER statement in SQL or through the Firebolt Workspace. Example The following code creates a new userskate
and bob
:
sales
role to kate
and revokes it from bob
:
Objects and permissions
Permissions in Firebolt define the actions or operations that can be performed, such as managing databases and engines, running queries, or accessing data. Each instance of a securable object, or an object that can be protected by access controls, has specific permissions that are associated with it, controlling what users can do with it. Examples of securable objects include databases, tables, and engines. If there are multiple instances of an engine object, each instance has its own set of predefined permissions. For a full list of available permissions, see role-based access control Any permission that Firebolt supports can be granted or revoked to or from roles.Privileges can be granted or revoked only for roles, not directly for users. Once a role has the necessary permissions, it can then be assigned to users, allowing them to inherit those privileges.
sales
role permission to use the sales_db
database, allows the role to access any database within dev_account
, and revokes the ability of the sales
role to start or stop the sales_eng
engine: