Securing Cloud Databases: Best Practices with ClickHouse and Wiz

How to protect sensitive data in cloud-hosted databases with built-in security controls, best practices, and continuous risk monitoring.

Recent incidents like the Deepseek AI database leak highlight how misconfigurations in cloud-hosted databases can expose sensitive data (Blogpost) . As organizations increasingly rely on cloud-native services, securing these environments is critical. The shared responsibility model places the onus on organizations to properly configure and monitor cloud infrastructure, making misconfigurations a leading cause of data exposure. A key challenge is maintaining continuous visibility—where is sensitive data stored, who has access to it, and how is it secured?Best practices and OOTB security controls provided by vendors help reduce misconfigurations, but security teams must also proactively monitor for drifts and policy violations.

ClickHouse, an open-source column-oriented database, offers built-in security features to help protect data. However, as cloud environments scale, security teams need deeper insights into potential risks, including misconfigurations and excessive access. By combining ClickHouse’s best practices with Wiz’s cloud security platform, organizations can continuously map their data exposure, detect risky configurations, and enforce security policies before an issue leads to a breach.

Note- While this blog post focuses on security best practices for open-source (OSS) ClickHouse, these same principles are foundational to how we secure ClickHouse Cloud - where we go even further with additional managed protections. By following these guidelines, self-hosted users can align with the same security standards we enforce in our cloud environment, ensuring robust data protection whether running ClickHouse on-prem or in the cloud.

In the recentblogpost, The Wiz Research team was able to identify a publicly accessible ClickHouse database belonging to DeepSeek. Thanks to this effort, the DeepSeek team was able to secure their instance immediately.

At the time of writing, there are over thirty thousand ClickHouse instances reachable from the internet.

As ClickHouse becomes more mainstream, supporting a wide range of use cases including ML/AI, Observability and Analytics, it is crucial for developers and engineers to know how they can protect themselves from making the same mistakes.

Due to this reason, the ClickHouse engineering team, in collaboration with Wiz, is reflecting on the recent breach and out-of-the-box defaults as well as sharing practical tips to help users protect their data in this blog post.

Beyond the immediate impact on reputation and customer trust, the DeepSeek breach also carries potential financial, legal, and regulatory consequences. The visibility of this incident was particularly high, trending on Hacker News for several days, raising broader concerns aboutdatabase security.

This naturally leads to the question—how did this happen, and what went wrong?As the maintainers of ClickHouse, we must also ask ourselves:Could we have done something better?

At first glance, the issue seems simple—the database should not have been publicly exposed. While that may be true for this specific deployment, ClickHouse can be safely deployed and exposed to the public when configured correctly. This is demonstrated by ourpublic demo environments, where users can freely query datasets, even accessing underlying databases directly for analysis. Additionally, standard services in ClickHouse Cloud (excluding Private Link) are publicly accessible for user connections, with the option to add IP filtering.

The key difference is that in these properly configured deployments, we enforce several best practices, including enabling TLS, securing the administrator account with authentication, and applying strict authorization policies for API users. In DeepSeek’s case, none of these protections were in place, leaving the instance completely unprotected.

> Note that in the case of public demos (for example,https://sql.clickhouse.com/), we share password-less credentials with our users, but enforce strict access controls through RBAC, as well limits on query complexity and quotas to prevent abusive usage.

The next question might be: how easy is this to do as a new user of ClickHouse? Was this simply the result of poor configuration defaults for whichother databaseshave suffered?

ClickHouse implements multiple security controlsduring installationto prevent misconfigurations that could leave an instance publicly accessible without authentication or encryption. However, this incident has also highlighted opportunities for further strengthening our default protections.

During installation, administrators are prompted to set a password for the default user. If they choose to proceed without one, an explicit acknowledgment is required, ensuring they are aware of the security implications.

>Why allow users to skip authentication?This is a trade-off between security and usability. While the default user is restricted, this approach supports valid use cases like local testing and development, ensuring ease of setup without compromising control when stricter security is required.

However, in reviewing the DeepSeek incident, we recognized that the default user inDocker deploymentscould be created without a password. While this still required users to explicitly publish ports to expose the instance, it introduced a potential risk. To address this, we have nowdisabled all network access for the default user by default in official ClickHouse images. This change has been backported to the last three releases and two LTS versions, ensuring improved security for existing deployments.

Note that a standard ClickHouse installation does not expose the server to external networks, even if no password is set for the default user during setup. To allow external access, users must manually adjust ClickHouse’s network settings.

This behavior can be seen in this part of thecode, preventing external access when nolisten_hostsetting is configured. Any changes to this configuration come with an explicit warning, emphasizing the need for careful consideration before exposing the instance to external connections.

The screenshot below demonstrates the default configuration where all examples of listen_host configurations are commented out by default, as the result, ClickHouse server falls back to only listens on the localhost interface.

While this limits direct exposure, there is still a risk—reverse proxy attacks, for example, could inadvertently expose the instance. To mitigate this, westrongly recommend setting a password for the default useras a baseline security measure.

In summary, the following misconfiguration was introduced to DeepSeek’s ClickHouse instance:

Publicly exposed without restrictions –The instance was accessible from the internet without IP filtering or binding to a private interface, leaving it vulnerable to unauthorized access.

No SSL/TLS encryption –Traffic was unencrypted, despite ClickHouse supporting TLS with Let’s Encrypt, making it trivial to secure connections.

Default user without a password –Authentication was not enforced, a critical misstep that should have been addressed during installation.

These represent the bare minimum security measures we recommend. While such configurations may be acceptable for local development and testing, production deployments require stricter security controls. Fortunately, ClickHouse has evolved over 15 years as a mature open-source project, offering robust security features to help teams safeguard their data effectively.

Out of the box, the OSS version of ClickHouse offers features such as:

Authentication & Access Control– Enforce secure authentication with password policies, certificate-based logins, SSH keys, and external providers like LDAP and Kerberos.

Role-Based Access Control (RBAC)– Grant fine-grained permissions to users and roles, ensuring controlled access to databases, tables, and system resources.

Query Quotas & Execution Limits– Prevent excessive resource consumption and data exfiltration by restricting query complexity, memory usage, and result sizes.

Network Security– Secure data in transit with SSL/TLS and mTLS, restrict network access with firewall policies, and limit exposure by configuring ClickHouse to listen only on required interfaces.

Data Encryption & Protection– Protect data at rest with virtual file system encryption and support secure storage on external disks (e.g., S3) to mitigate file system attacks.

Secret Management– Store and manage credentials securely using named collections, IAM roles, and automatic query masking to prevent credential leakage.

Auditing & Monitoring– Maintain visibility with detailed logs of authentication attempts, queries, and system activity, ensuring compliance and detecting suspicious behavior.

We’ll explore each of these in a little more detail and provide guidance when each is appropriate.

By default, authentication relies on passwords, with users strongly encouraged to set a password for the default user during installation as emphasized earlier. Passwords are hashed using SHA-256 with a salt, preventing them from being stored in plain text.

Over time, we’ve improved password hashing mechanisms, initially supportingSHA-256 with salt and double SHA-1 before introducing bcrypt, a slower hashing algorithm designed to meet industry best practices. Additionally,password complexity rulescan be enforced to comply with NIST 800-63B Authenticator Assurance Level 1.

CREATEUSERsec_userIDENTIFIEDWITHbcrypt_hashBY'$2y$10$3y43Ch......J9klbw4Twhy8YLm'

Beyond passwords, ClickHouse supports other authentication methods suited for different security needs.Certificate authenticationallows secure, encrypted connections between services and ClickHouse without relying on traditional passwords.

CREATEUSERsec_userIDENTIFIEDWITHssl_certificate CN 'serviceA.customer.com'

More recently,SSH key authenticationhas been added, making it easier for developers to securely work with ClickHouse while avoiding credential management.

CREATEUSERsec_userIDENTIFIEDWITHssh_keyBYKEY'AAAAC3NzaC1lZDI...AtNYgwncUnjaSl4e1Od'TYPE`ssh-ed25519`

For self-managed enterprise environments, ClickHouse integrates withexternal authentication providers, including LDAP for centralized authentication, HTTP endpoints for custom authentication flows, and Kerberos for single sign-on.

Finally, ClickHouse also provides additional controls to further restrict access. TheVALID UNTILsetting ensures temporary access is automatically revoked after a specified period, reducing the risk of stale credentials. Authentication can also be restricted by IP using theHOST setting, preventing unauthorized access from untrusted locations.

CREATEUSERsec_user_5IDENTIFIEDWITHbcrypt_hashBY'$2y$10$3y43Ch......J9klbw4m'VALIDUNTIL'2025-03-01'HOST IP'10.1.1.0/24'

These authentication and access control mechanisms ensure that ClickHouse can be deployed securely while remaining flexible enough to support a wide range of use cases.

ClickHouse provides fine-grainedRole-Based Access Control (RBAC), allowing administrators to precisely manage permissions by granting and revoking privileges at the user or role level to databases, tables and system resources.

Permissions can be assigned to individual users or roles, making it easier to manage access across multiple accounts. Administrators can grant specific privileges, such asSELECT, CREATE, and INSERT, on particular databases or tables. They can also revoke permissions when necessary to maintain security.

GRANTSELECTONsystem.*TO`developer_role`;REVOKESELECTONsystem.query_*FROM`developer_role`;GRANTSELECT,CREATE,INSERTON`developer_db`TO`dev_user`;

Multiple roles can also be assigned directly to users or even nested within other roles to simplify permission management.

GRANT`developer_role`, `analytic_role`TO`dev_user`;

For cases where users need to delegate permissions, ClickHouse supportsWITH GRANT OPTION, allowing them to pass on granted privileges to others:

GRANT*ON`developer_db`TO`dev_user`WITHGRANTOPTION;

Beyond granting access at the database or table level, ClickHouse also supportsboth static and dynamic row-level security policies. These policies ensure that users only see specific subsets of data based on predefined conditions. This is particularly useful when restricting access to sensitive records while allowing broader queries on the same table.

-- Static Row Policy: Grants access to rows where security_tag = 'analytic'CREATE ROW POLICY analytic ON secure.data USING security_tag='analytic' TO analytic_role

-- Dynamic Row Policy: Grants access based on user-specific tags retrieved dynamically from HTTP RequestCREATE ROW policy header_fun ON secure.data FOR SELECT USING security_tag IN(  SELECT tag from security_tag_referenceWHERE user=getClientHTTPHeader('X-USER'))TO grafana

When exposing ClickHouse instances to untrusted users or restricting internal users from consuming excessive resources, administrators can enforcequery quotasandcomplexity limitsto prevent performance issues and unauthorized modifications. These measures ensure controlled resource usage while maintaining system stability.

To prevent accidental changes in production environments, administrators can enforce read-only access for certain users by setting`readonly=1`. This is ideal for service accounts or roles that should only perform queries without modifying the data.

CREATEUSERsec_user_5IDENTIFIEDWITHbcrypt_hashBY'$2y$10$3y43ChJKzPN15xbS400e6eQSgDtV7.zqU0mffFJ9klbw4Twhy8YLm'readonly=1;

Beyond read-only restrictions, ClickHouse providesquota managementto prevent excessive data retrieval and limit system resource consumption. Administrators can configure limits on parameters such asmax_rows_to_readandmax_memory_usage. These features are extensively used in public demo environments and are recommended for usersexposing ClickHouse instances externally. Additional limits enforced bymax_result_rows, `max_result_bytes` can help prevent the large exfiltration of data.

CREATEUSERsec_user_5IDENTIFIEDWITHbcrypt_hashBY'$2y$10$3y43Ch......J9klbw4m'VALIDUNTIL'2025-03-01'HOST IP '10.1.1.0/24'SETTINGSmax_memory_usage=100000,max_rows_to_read=10000,max_result_rows=10;

For more scalable access control,settings profilesallow administrators to group multiple constraints into a single profile, which can then be assigned to users or roles. This simplifies configuration management and ensures consistency across different user groups.

CREATESETTINGSPROFILE `play`SETTINGSreadonly = 1, max_execution_time = 60, max_rows_to_read = 10000000000, max_result_rows = 1000, max_bytes_to_read = 1000000000000, max_result_bytes = 10000000, max_network_bandwidth = 25000000, max_memory_usage = 20000000000, max_bytes_before_external_group_by = 10000000000, enable_http_compression = true--assign settings profile to the roleALTERUSERplaySETTINGSPROFILE play_role

By applying query quotas, read-only restrictions, and settings profiles, administrators can confidently expose ClickHouse to external users while ensuring fair resource distribution.

When exposing ClickHouse to external users or limiting internal access, network security plays a crucial role in preventing unauthorized access and data breaches. Basic best practices include using firewalls and restricting security groups to only allow traffic from legitimate sources.

For ClickHouse itself, administrators should enforceTLS encryption to secure data in transitand prevent interception. As noted in the Deepsesk breach retrospective, server network interfaces are equally important - ClickHouse shouldonly listen on explicitly required addresses, disabling any unnecessary interfaces to reduce the attack surface.

<!-- Restrict ClickHouse to listen only on a specific private IP --><listen_host>10.1.1.100</listen_host><!-- Disable wildcard binding to prevent exposure on public networks --><!-- <listen_host>::</listen_host> --><!-- <listen_host>0.0.0.0</listen_host> -->

For production deployments, especially those exposed to external traffic, enabling TLS is essential. As described inour documentation, securing client connections is straightforward thanks to  Let’s Encrypt certificates.

https_port: 8443tcp_port_secure: 9440openSSL:server:certificateFile: '/etc/clickhouse-server/fullchain.pem'privateKeyFile: '/etc/clickhouse-server/privkey.pem'disableProtocols: 'sslv2,sslv3,tlsv1,tlsv1_1'

By following these best practices administrators can significantly enhance ClickHouse’s security while maintaining accessibility for legitimate users.

When handling sensitive data, encryption plays a critical role in protecting ClickHouse instances from unauthorized access. ClickHousesupports encryption at restandbuilt-in encryption functionsfor data security at different levels.

Encryption at rest is achieved through virtual file system encryption and the ability to store data onexternal disks such as S3. This ensures that even if an attacker gains access to the underlying file system, they cannot directly extract sensitive data. Storing data externally also mitigates risks from Local File Inclusion (LFI) and adds an additional layer of defense by slowing down the attacker in the event of a Remote Code Execution (RCE) attack.

In addition to encryption at rest, ClickHouse provides built-in functions toencryptanddecryptdata at query time, allowing developers to control access to sensitive information dynamically. The example below demonstrates how to use AES-256 encryption and decryption within a query:

WITH (SELECTencrypt('aes-256-ofb', 'ClickHouse has security functions', 'a_32characterkeylengthisrequired'))ASencrypt_tokenSELECTdecrypt('aes-256-ofb', encrypt_token, 'a_32characterkeylengthisrequired');

┌─decrypt('aes-256⋯ [HIDDEN id: 2])─┐

│ ClickHouse has security functions │

└───────────────────────────────────┘

When integrating ClickHouse with external services such asS3,PostgreSQL, orMongoDB, credentials are often required.

For self-managed deployments, ClickHouse providesnamed collections, allowing credentials to be securely stored and referenced within queries instead of being part of the query.

> In ClickHouse Cloud environments,IAM roles can be used for authenticationwhen accessing S3, removing the need to store static credentials.

This reduces the risk of exposing sensitive information in logs or query history.Named collectionscan be configured in config.xml and referenced in queries:

<clickhouse>

<named_collections>

<s3_mydata>

<access_key_id>AKIAIOSFODNN7EXAMPLE</access_key_id>

<secret_access_key>wJalrXEXAMPLEKEYEXAMPLEKEYEXAMPLEKEY</secret_access_key>

<format>CSV</format>

<url>https://s3.us-east-1.amazonaws.com/yourbucket/mydata/</url>

</s3_mydata>

</named_collections>

</clickhouse>–or via DDL

CREATE NAMED COLLECTION s3_mydata AS

access_key_id = 'AKIAIOSFODNN7EXAMPLE',

secret_access_key = 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY',

format = 'CSV',

url = 'https://s3.us-east-1.amazonaws.com/yourbucket/mydata/'

Queries can then reference the named collection instead of including credentials directly:

INSERTINTOFUNCTIONs3(s3_mydata, filename = 'test_file.tsv.gz',format= 'TSV', structure = 'number UInt64', compression_method = 'gzip')SELECT*FROMnumbers(10000);

Additionally, ClickHouse automatically masks credentials in logs when table functions require authentication.

To further enforce security, query masking rules can be applied via regex to sanitize logs, preventing accidental exposure of sensitive information. These rules can be configured in config.xml underquery_masking_rules.

By combining IAM roles, named collections, log masking, and query masking rules, ClickHouse ensures secure credential management while minimizing exposure risks.

For security purposes, thelogging tablesin ClickHouse’ssystem databaseprovide a detailed audit log, allowing administrators to easily analyze past events.

Insystem.session_log, administrators can find information about successful and unsuccessful authentication attempts such as event time, source IP address, the type of client used, the network interface they tried to connect.

Withsystem.query_log, administrators can review past user queries with detailed information, including the query timestamp, execution time, number of rows and bytes returned, query string, originating IP address the client used to execute the query and many other helpful information.

In the event of a Denial of Service attack,crash_log,error_logandtext_logcould assist administrators in identifying the root cause and implementing mitigation measures.

ClickHouse OSS serves as the foundation for our SaaS platform,ClickHouse Cloud. As a result, our engineers always maintain a high standard for our open source project to ensure stability and security for both OSS users and our Cloud customers. Our commitment is demonstrated through continuousfuzzingeffort and abug bounty programthat encourages security researchers to identify and report potential vulnerabilities.

Building on this strong foundation, ClickHouse Cloud enables customers to harness the performance and scalability of ClickHouse with confidence in its security. As a fully managed service, it offersSSO integration,customer-managed encryption keys,compute-compute separation, and many othersecurity-focused features. ClickHouse Cloud has undergone rigorous compliance audits, meetinghigh standards such as ISO 27001, SOC 2 Type 2, PCI DSS, and HIPAA, ensuring best-in-class security practices. For more details, visit ourTrust Center.

Implementing best practices is a foundational step toward securing cloud-hosted databases, but without continuous monitoring, toxic combinations/misconfigurations can easily go unnoticed. Security teams can leverage Wiz to:

Surface risky configurations: Wiz automatically identifies exposed Clickhouse instances, misconfigured access controls, and overly permissive network settings across cloud environments. Here are two quick steps you can take in Wiz to surface these insights.

Clickhereto find your instances of Clickhouse.

(Navigate to Inventory and under technologies you can search for ‘Clickhouse’)

Clickhereto identify any publicly exposed Clickhouse instances.

Clickhereto identify if you have a misconfiguration that allows remote unauthenticated access to the Clickhouse database API.

(Navigate to Policy - Host Configuration Rules and search for Clickhouse). The ‘Clickhouse allows remote anonymous access to API database’ rule checks if there is a misconfiguration allowing remote unauthenticated access to their database API)

Prioritize risk based on context: Wiz enriches security findings with context from cloud infrastructure, helping teams focus on the risks that pose the greatest threat to sensitive data.

Monitor changes over time: Cloud environments are dynamic, with configurations constantly evolving. Wiz provides continuous assessment to help teams catch newly introduced risks before they lead to exposure.

Enable proactive remediation: Security teams can set up automated alerts and remediation workflows in Wiz to quickly address high-risk findings.

By integrating Wiz into their cloud security operations, organizations can build a scalable approach to protecting Clickhouse deployments and other cloud-hosted data services. Combining best practices with continuous risk monitoring ensures that security doesn't stop at configuration—it becomes an ongoing process of identifying, prioritizing, and mitigating risks in cloud environments.

Discover how Wiz can help you secure your cloud environments including your data services. Request a personalized demo to address your specific requirements.

A supply chain attack on tj-actions/changed-files caused many repositories to leak their secrets over the weekend. Wiz Research has discovered an additional supply chain attack on reviewdog/actions-setup@v1, that may have contributed to the compromise of tj-actions/changed-files.

A supply chain attack on popular GitHub Action tj-actions/changed-files caused many repositories to leak their secrets. Discover how it unfolded and the steps to mitigate the risk.

From DeepSeek adoption to impact on security and governance.

Get a personalized demo

©2026Wiz, Inc.

StatusPrivacy PolicyTerms of UseModern Slavery StatementCookie Settings