InfluxDB Cloud Dedicated security

InfluxData’s information security program is based on industry-recognized standards and frameworks, including but not limited to ISO 27001, NIST 800-53, CIS20, and SOC2 Type II. The security policy describes the secure development, deployment, and operation of InfluxDB Cloud.

To protect data, InfluxDB Cloud Dedicated includes the following:

• Guaranteed tenant isolation and data integrity.

• Trusted cloud infrastructure including Amazon Web Services (AWS), Microsoft Azure (Coming), and Google Cloud Platform (GCP) (Coming), building on security controls of these cloud providers, such as physical security, disk encryption, and key management services (KMS).

• Comprehensive application and service security covering technical security measures and the people and processes that maintain the platform, including:

  • Internal access controls
  • Configuration management
  • Secure software development life cycle SDLC
  • Separation of environments and duties
  • Monitoring, logging, and alerting
  • Security assessments
  • Business continuity and disaster recovery
  • Data durability
  • Incident response

• Configurable security controls

  • Access, authentication, and authorization
    • User provisioning
    • Management tokens
    • Database tokens
      • Token rotation
  • Role-based access controls RBAC
  • Advanced controls

• Compliance auditing to ensure continuous review and adoption of industry-recognized standards and best practices.

Tenant isolation

In the InfluxDB Cloud Dedicated platform, access controls ensure that only valid authenticated and authorized requests access your account data. Access control includes:

• A unique cluster ID assigned to each InfluxDB Cloud Dedicated cluster. All internal Cloud services require this cluster ID to authenticate entities before accessing or operating on data.
• All external requests must be authorized with a valid token or session. Every InfluxDB Cloud Dedicated service enforces this policy.

Data integrity

A dedicated internal service ensures data integrity by periodically creating, recording, and writing test data into test buckets. The service periodically executes queries to ensure the data hasn’t been lost or corrupted. A separate instance of this service lives within each InfluxDB Cloud Dedicated cluster. Additionally, the service creates out-of-band backups in line protocol, and ensures the backup data matches the data on disk.

Cloud infrastructure

InfluxDB Cloud Dedicated is available on the following cloud providers:

• Amazon Web Services (AWS)
• Microsoft Azure (Coming)
• Google Cloud Platform (GCP) (Coming)

To ensure data security, availability, and durability, each instance is isolated and protected in its own virtual private cloud (VPC).

Users interact with InfluxDB Cloud Dedicated only through Cloud Dedicated established APIs. For cluster management activities, authorized users interact with the Granite service. For workload clusters, authorized users interact with APIs for InfluxDB v3 Ingesters (writes) and Queriers (reads). These services don’t expose AWS S3 or other cloud provider or internal services. InfluxDB Cloud Dedicated uses separate S3 buckets for each customer’s cluster to persist writes. The S3 buckets are only accessible by the customer’s cluster services. Separate configuration ensures one customer’s S3 buckets cannot be accessed by another customer (for example, in the event of a service defect).

Amazon Web Services (AWS)

An instance of InfluxDB Cloud Dedicated consists of microservices in Kubernetes. Each VPC within AWS is segmented into public and private subnets:

• The public subnet contains resources exposed to the public internet, including load balancers and network address translation (NAT) gateways.
• The private subnet contains supporting infrastructure (for example, compute and storage) not exposed to the public internet.

AWS data centers are compliant with many physical and information security standards. For detail about AWS’s physical security and data center protocols, see AWS’s Compliance.

Google Cloud Platform (GCP)

In Google Cloud Platform (GCP), InfluxDB Cloud Dedicated uses the Google Kubernetes Engine (GKE) and Google Compute Engine to deploy individual cluster components. Clusters are isolated at the project level to enhance access controls and data governance, and support auditing.

Google Cloud Platform data centers are compliant with many physical and information security standards. For detail about physical security in GCP data centers, see Google’s Compliance website.

Microsoft Azure

In Microsoft Azure, InfluxDB Cloud Dedicated uses Azure Kubernetes Service (AKS) and Azure Virtual Machines to deploy individual cluster components. To support auditing and authorization control within Azure, clusters are deployed into dedicated VNets within each region.

Microsoft Azure data centers are compliant with many physical and information security standards. For detail about physical security within Microsoft Azure data centers, see Microsoft’s Compliance website.

Data encryption

InfluxDB Cloud Dedicated enforces TLS encryption for data in transit from all clients, including Telegraf agents, browsers, and custom applications. TLS 1.2 is the minimum TLS version allowed by InfluxDB Cloud Dedicated, including Granite server and management cluster TLS termination. Requests using TLS 1.1 or earlier are rejected.

By default, data at rest is encrypted using strong encryption methods (AES-256) within AWS, GCP, and Microsoft Azure. S3 buckets are encrypted by default (and not configurable otherwise).

User managed encryption keys are not supported in InfluxDB Cloud at this time.

Application and service security

InfluxData maintains the following application and service security controls:

Internal access controls

• Administrative privileges are restricted to named groups of authorized users.
• Shared accounts are prohibited.
• Multi-factor authentication (MFA) is required for all infrastructure (AWS, GCP, and Azure) and for other production systems with access to user information (see InfluxData Subprocessors).
• InfluxDB Cloud Dedicated access is logged and audited regularly.

Configuration management

InfluxDB Cloud Dedicated is programmatically managed and deployed using “infrastructure as code” which undergoes version control and testing as part of the automated deployment process. Permission to push code is tightly controlled, requiring peer review and approval by designated infrastructure engineers, and has automated safeguards to prevent production-impacting events.

Secure software development life cycle (SDLC)

InfluxData follows security best practices throughout the development cycle, including:

• Security control points at multiple phases of development.
• Manual security code review on critical assets.
• Security considered in the design phase, starting with architecture review and threat modeling.
• Source code management:
  • Version control
  • Mandatory peer code review
  • Automated functional testing and static code analysis
  • Automated vulnerability scans on third-party dependencies and libraries
• Automated vulnerability scans on containers
• Regular dynamic application security testing and third-party penetration tests
• Regular engineering team training in secure application development practices

Separation of environments and duties

Production and non-production environments are separate. Developers use non-production environments solely for development, testing, and staging, and do not use user data for non-production use cases. Production access is limited to authorized personnel based on the principles of least privilege and separation of duties.

Monitoring, logging, and alerting

InfluxData continuously monitors and analyzes metrics from InfluxDB Cloud Dedicated environments.

• Services are carefully monitored to ensure performance and availability, and to detect anomalies.
• Application logging, performance, and observability data are gathered and used for event analysis, capacity planning, alerting, and instrumentation. Access to these logs and operator interfaces is controlled by group access permissions, and provided only to teams that require access to deliver InfluxDB Cloud Dedicated services.

Security assessments

InfluxData uses trusted third-party security firms to complete penetration testing to discover vulnerabilities post-development, and validate remediations from previous engagements. This includes white box and gray box testing against InfluxDB Cloud.

Business continuity and disaster recovery

InfluxData is a highly distributed organization with employees located across the globe. InfluxData IT infrastructure is cloud-based and there is no on-premise infrastructure. This allows InfluxData teams to access services from anywhere around the globe and rely upon the disaster recovery capabilities of service providers to ensure InfluxData’s business continuity. As a cloud-native company, all of InfluxData’s business functions that are provided by cloud vendors rely on those vendors’ Service Level Agreements (SLA) to maintain the services they provide. The Business Continuity Plan and Disaster Recovery Plan are updated annually.

Data durability

Data is replicated within multiple storage engines of InfluxDB Cloud Dedicated. The replication mechanism executes a serializable upsert and delete stream against all replicas and runs background entropy detection processes to identify diverged replicas. Ingested data is also recorded out of band to provider-operated object storage.

Incident response

Report security incidents to security@influxdata.com or support@influxdata.com. InfluxData maintains procedures for incident alerting and response, performance or downtime events, security, and customer notification. We perform root cause analysis (RCA) as part of our incident response.

Configurable security controls

Users can configure the following security controls:

Access, authentication, and authorization

InfluxDB Cloud Dedicated separates workload cluster management authorizations (using management tokens) from database read and write authorizations (using database tokens).

• User provisioning
• User groups
• Management tokens
• Database tokens

User provisioning

InfluxData follows security best practices for creating user accounts and managing permissions to resources.

InfluxData Support creates user accounts with user group permissions for access to InfluxDB Cloud Dedicated cluster resources. After creating the user account, InfluxData provides the user with the following:

• A login URL for authenticating access to the cluster
• The InfluxDB Cloud Dedicated account ID
• The InfluxDB Cloud Dedicated cluster ID
• The InfluxDB Cloud Dedicated cluster URL
• A password reset email for setting the login password

With a valid password, the user can login by invoking one of the influxctl commands. The command initiates a browser login between the identity provider and the user so that the password is never exchanged with influxctl. After a successful authentication, InfluxDB Cloud Dedicated provides the user’s influxctl session with a short-lived management token for access to the Granite service. The user interacts with the influxctl command line tool to view or manage cluster resources. The user groups assigned to the user determine the level of access to resources.

User groups

User groups associate access privileges with user attributes–an important part of the Attribute-Based Access Control (ABAC) security model, which grants access based on user attributes, resource types, and environment context.

In InfluxDB Cloud Dedicated, a user can belong to any of the following user groups, each with predefined privileges:

• Admin user group
• Member user group
• Auditor user group

Admin user group

Admins are InfluxDB Cloud Dedicated users who have read and write permissions on all resources (for all clusters) in the account. Only Admins can create management tokens.

Member user group

Members are InfluxDB Cloud Dedicated users who have read permission on certain resources and create permission for database tokens. Members can’t delete or create databases or management tokens.

Auditor user group

Auditors are InfluxDB Cloud Dedicated users who have read permission on all resources (for all clusters) in the account; auditors can’t modify account resources.

Management tokens

Management tokens authenticate user accounts to the Granite service and provide authorizations for workload cluster management activities, including:

• account, pricing, and infrastructure management
• inviting, listing, and deleting users
• creating, listing, and deleting databases
• creating, listing, and deleting database tokens

Management tokens consist of the following:

• An access token string (sensitive)
• A permission set for management activities (configured during user provisioning)
• For tokens generated by logging in to influxctl, a mandatory 1 hour expiration

In InfluxDB Cloud Dedicated, management tokens may be created by the account’s identity provider for user authentication in clients, such as influxctl, or they may be manually created by Admin users for automation using the Management API.

• Management tokens in the influxctl CLI
• Management tokens and the Management API

Management tokens in influxctl CLI

In InfluxDB Cloud Dedicated, the account’s identity provider creates management tokens for user authentication in tools such as influxctl. When a user issues a command using the influxctl command-line tool, influxctl sends the management token string with the request to the server, where Granite validates the token. If the management token is valid and not expired, the service then compares the token’s permissions against the permissions needed to complete the user’s request.

Only valid unexpired tokens that have the necessary permission sets are authorized to perform management functions with InfluxDB Cloud Dedicated. Following security best practice, management tokens are never stored on InfluxDB Cloud Dedicated (Granite or workload cluster) servers, which prevents token theft from the server. On the client (the user’s system), the management token is stored on disk with restricted permissions for influxctl to use on subsequent runs. For example, a user’s Linux system would store the management token at ~/.cache/influxctl/*.json with 0600 permissions (that is, owner read and write, and no access for group or other).

Management tokens and the Management API

For automation use cases, Admins can manually create and revoke long-lived management tokens for use with the Management API–for example, to rotate database tokens or create tables.

Manually created management tokens:

• aren’t affected by user group permissions
• have an optional expiration and don’t require human interaction with the OAuth provider
• are for automation use cases
• shouldn’t be used to circumvent the OAuth provider

To authenticate a Management API request, the user passes the manually created token in the HTTP Authorization header:

Authorization MANAGEMENT_TOKEN

Database tokens

Admins and Members, can create database tokens for database read and write access. Database tokens provide authorization for users and client applications to read and write data and metadata in an InfluxDB Cloud Dedicated database. All data write and query API requests require a valid database token with sufficient permissions. Note: an all-access management token can’t read or write to a database because it’s not a database token.

Database tokens consist of the following:

• An identifier
• A description
• A permission set for reading from a database, writing to a database, or both
• An API key string (sensitive, with the format apiv_<base64-encoded 512-bit random string>)

When a user successfully creates a database token, the InfluxDB Cloud Dedicated Granite server reveals the new database token to the user as an API key string–the key string is only visible when it’s created. The user is responsible for securely storing and managing the API key string.

Following security best practice, a database token’s raw API key string is never stored on InfluxDB Cloud Dedicated (Granite or workload cluster) servers, which prevents token theft from the server. The servers store non-sensitive database token attributes (identifier, description, and permission set) and the SHA-512 of the token API key string. When a user provides the API key as part of a request to the workload cluster, the cluster validates the token’s SHA-512 against the stored SHA-512. If the database token is valid, InfluxDB Cloud Dedicated compares the token’s permissions against the permissions needed to complete the user’s request. The request is only authorized if it contains a valid token with the necessary permission set.

Token rotation

Database tokens don’t have an expiration. Users authorized for management activities can revoke a database token by deleting it. To rotate a token, a user deletes the database token and issues a new one.

Role-based access controls (RBAC)

InfluxDB Cloud accounts support multiple users in an organization. By default, each user with the Owner role has full permissions on resources in your InfluxDB Cloud Dedicated cluster.

Advanced controls

Users needing stricter security around data access and risk mitigation measures should implement the following:

• Single sign-on (SSO). Authentication requests from a particular email domain can be routed to an Enterprise SSO provider for authentication before they are provided with a valid management token. If you would like to set this up, please contact sales@influxdata.com.
• Multi-factor authentication (MFA). InfluxData can enable MFA via an Enterprise SSO connection. MFA is then enabled on the user’s Enterprise SSO authentication provider. If you would like to set this up, please contact sales@influxdata.com.
• Periodic Token rotation. Users should periodically delete their current database tokens and create new tokens.

Compliance and auditing

InfluxDB Cloud is SOC2 Type II certified. To request a copy of the SOC2 Type II report, or for information on the ISO 27001 Information Security Management System, contact sales@influxdata.com.