> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-parallel-read-in-order-multi-part.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# ClickHouse data access（BYOC）

> ClickHouse 员工在 BYOC 部署中可访问哪些客户数据

默认情况下，ClickHouse 员工无权访问您的数据。您的 ClickHouse 数据 (包括所有用户表和查询结果) 始终保留在您自己的云账户内。以下是 ClickHouse 与您的部署发生交互的唯一途径——但这些途径均不会授予对客户表数据的访问权限。

<h2 id="routine-operations">
  日常运维操作
</h2>

ClickHouse Cloud 的 control plane 在不读取客户数据的前提下运行你的 BYOC deployment。向 ClickHouse 自有基础设施发送数据的组件仅传输运维层面的元数据：

| 组件 | 到达 ClickHouse 自有基础设施的内容 |
| - | - |
| 状态导出器 | service 与 backup 的状态 (健康状况、status —— 均为运维事件，而非 backup 内容) ，发送至 ClickHouse Cloud 自有的队列：AWS 上为 `SQS`，GCP 上为 Pub/Sub，Azure 上为 Service Bus。 |
| Billing scraper | CPU 与内存 metrics，发送至 ClickHouse Cloud 自有的 object storage bucket。 |
| AlertManager | cluster 健康状况告警，发送至 ClickHouse Cloud。 |

查询流量、表内容以及 schema 绝不会经由这些通道传输。你的完整监控数据集 —— 包括 Prometheus 与 Thanos 技术栈以及你的 日志 —— 始终保留在你自己的 account 中；上表中列出的有限 telemetry 是唯一会持续导出到 ClickHouse 自有系统的可观测性数据。此外，ClickHouse 的监控仪表板以及经审批处理后的 ClickHouse 工程师，可通过 Tailscale 就地查询该技术栈和你的 日志，且不会在 ClickHouse 一侧持久化任何内容 —— 参见[故障排查访问](#troubleshooting-access)。完整的入站与出站流量参考，请参见[网络边界](/zh/products/bring-your-own-cloud/reference/network-security#network-boundaries)。

<h2 id="troubleshooting-access">
  故障排查访问
</h2>

当 ClickHouse 工程师需要诊断您部署中的问题时，他们会通过内部处理和审批工作流申请即时访问权限。获批的访问权限通过有时限的证书授予，并经由 [Tailscale](/zh/products/bring-your-own-cloud/reference/network-security#tailscale-private-network) 路由——绝不会通过公共互联网。

<h3 id="what-engineers-can-see">
  工程师可以查看哪些内容
</h3>

在 ClickHouse 内部，获得批准的故障排查访问权限仅限于系统表。包括：

* `system.query_log` — 针对您的 service 运行的查询的查询文本和执行元数据
* `system.tables`、`system.columns` 以及类似的系统表 — schema 和元数据
* 其他用于诊断的 `system.*` 表 (例如：parts、变更、副本)

<h3 id="what-engineers-cant-see">
  工程师无法查看的内容
</h3>

工程师无法读取客户的用户表数据。在 ClickHouse 中,访问权限仅限于系统表。

<h3 id="infrastructure-diagnostics">
  基础设施诊断
</h3>

同样需经审批的处理流程还可单独授予限时权限，用于通过 Tailscale 访问基础设施相关的操作面：Kubernetes API server，以及集群内的监控技术栈和日志。这与上文所述的 ClickHouse 访问属于彼此独立的范围——其中不包含任何客户表数据，通过它读取的内容也不会在 ClickHouse 侧持久化。

<h3 id="how-access-is-enforced">
  如何执行访问控制
</h3>

* **需要审批**：每个访问请求都必须经过内部审批系统，并由指定审批人批准。工程师不能自行授予自己访问权限。
* **有时限的证书**：系统会为每个获批会话生成临时的时效性证书。访问权限会自动失效。
* **基于证书的身份验证**：对于对 BYOC 实例的所有人工访问，均使用证书替代基于密码的访问方式。
* **系统表只读**：证书对应的身份权限仅限于读取系统表。
* **ClickHouse 侧不留存任何内容**：故障排查会话期间读取的结果——无论来自系统表、监控技术栈还是您的日志——仅传输到工程师的工具中用于展示，不会存储在 ClickHouse 基础设施中，也不会回传到那里。

<h2 id="auditing">
  审计
</h2>

您可以查看工程师的活动，且这些活动会由 ClickHouse 进行审计：

* **客户可见 (ClickHouse) **：ClickHouse 工程师在您的实例上执行的每一条查询，都会出现在您自己的 `system.query_log` 中，其中包括查询文本和证书标识。您可以直接在您的 ClickHouse 服务中审计这些内容。
* **客户可见 (基础设施) **：`system.query_log` 无法展示上述基础设施层面的操作。Kubernetes API 调用会出现在您集群的 Kubernetes 审计日志中，云 API 调用会出现在您的云审计记录中，而 Tailscale 连接本身则会出现在您已启用的流日志中。有关各个云平台上这些日志的具体位置 (包括哪些默认开启) ，请参阅[审计边界](/zh/products/bring-your-own-cloud/reference/network-security#auditing-the-boundary)。
* **ClickHouse 侧**：ClickHouse 的安全团队会在内部记录并审计所有访问请求、审批以及 Tailscale 连接。

<h2 id="future-controls">
  未来控制功能
</h2>

客户控制审批——即每次工程师的访问请求生效前都需由您批准——已纳入路线图。目前，批准通过 ClickHouse 的内部处理流程完成。

<h2 id="related">
  相关内容
</h2>

* [BYOC 网络安全](/zh/products/bring-your-own-cloud/reference/network-security) — 了解 Tailscale 和网络边界如何工作
* [BYOC 权限](/zh/products/bring-your-own-cloud/reference/privilege) — BYOC 设置期间创建的 IAM 角色