> ## 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.

# Acceso a los datos de ClickHouse (BYOC)

> Qué acceso tienen los empleados de ClickHouse a los datos de los clientes en despliegues BYOC

Los empleados de ClickHouse no tienen acceso a sus datos de forma predeterminada. Sus datos de ClickHouse, incluidas todas las tablas de usuario y los resultados de las consultas, permanecen en su propia cuenta en la nube. A continuación se describen las únicas vías por las que ClickHouse interactúa con su implementación; ninguna de ellas otorga acceso a los datos de las tablas de los clientes.

<h2 id="routine-operations">
  Operaciones rutinarias
</h2>

El control plane de ClickHouse Cloud opera su implementación de BYOC sin leer los datos del cliente. Los componentes que envían datos a la infraestructura propiedad de ClickHouse transmiten únicamente metadatos operativos:

| Componente | Qué llega a la infraestructura propiedad de ClickHouse |
| - | - |
| State exporter | Estado del service y de los backups (salud, status: eventos operativos, no el contenido de los backups) a una cola propiedad de ClickHouse Cloud: `SQS` en AWS, Pub/Sub en GCP, Service Bus en Azure. |
| Billing scraper | Métricas de CPU y memoria a un bucket de object storage propiedad de ClickHouse Cloud. |
| AlertManager | Alertas de salud del clúster a ClickHouse Cloud. |

El tráfico de consultas, el contenido de las tablas y los esquemas nunca circulan por estos canales. Su conjunto completo de datos de monitorización (el stack de Prometheus y Thanos, y sus logs) permanece en su propia cuenta; la telemetría acotada que se detalla en la tabla anterior son los únicos datos de observabilidad que se exportan de forma continua a sistemas propiedad de ClickHouse. Los paneles de monitorización de ClickHouse y, previa escalado aprobada, sus ingenieros pueden además consultar ese stack y sus logs in situ a través de Tailscale, sin que nada se persista del lado de ClickHouse; consulte [acceso para solucionar problemas](#troubleshooting-access). Consulte [los límites de red](/es/products/bring-your-own-cloud/reference/network-security#network-boundaries) para obtener la referencia completa de los flujos entrantes y salientes.

<h2 id="troubleshooting-access">
  Acceso para solucionar problemas
</h2>

Cuando los ingenieros de ClickHouse necesitan diagnosticar un problema en su despliegue, solicitan acceso puntual mediante un flujo de trabajo interno de escalado y aprobación. El acceso aprobado se otorga mediante un certificado con tiempo limitado y se canaliza a través de [Tailscale](/es/products/bring-your-own-cloud/reference/network-security#tailscale-private-network), nunca por la Internet pública.

<h3 id="what-engineers-can-see">
  Lo que los ingenieros pueden ver
</h3>

Dentro de ClickHouse, el acceso aprobado para solucionar problemas se limita a las tablas del sistema. Esto incluye:

* `system.query_log` — texto de la consulta y metadatos de ejecución de las consultas realizadas en su servicio
* `system.tables`, `system.columns` y tablas del sistema similares — esquema y metadatos
* Otras tablas `system.*` utilizadas para diagnósticos (p. ej., partes, mutaciones, réplicas)

<h3 id="what-engineers-cant-see">
  Lo que los ingenieros no pueden ver
</h3>

Los ingenieros no pueden leer las tablas de usuario de los clientes. Dentro de ClickHouse, el acceso se limita únicamente a las tablas del sistema.

<h3 id="infrastructure-diagnostics">
  Diagnóstico de infraestructura
</h3>

El mismo proceso de escalado sujeto a aprobación puede otorgar por separado acceso limitado en el tiempo a superficies de infraestructura a través de Tailscale: el Kubernetes API server y la pila de monitorización y los logs internos del clúster. Se trata de una superficie distinta del acceso a ClickHouse descrito anteriormente: no contiene datos de tablas de clientes y nada de lo que se consulta a través de ella se persiste en el lado de ClickHouse.

<h3 id="how-access-is-enforced">
  Cómo se controla el acceso
</h3>

* **Aprobación obligatoria**: cada solicitud de acceso pasa por un sistema interno de aprobación con aprobadores asignados. Los ingenieros no pueden concederse acceso a sí mismos.
* **Certificados con tiempo limitado**: se genera un certificado temporal para cada sesión aprobada. El acceso expira automáticamente.
* **Autenticación basada en certificados**: los certificados sustituyen el acceso basado en contraseña para cualquier acceso humano a instancias de BYOC.
* **Solo lectura en las tablas del sistema**: la identidad del certificado solo permite leer tablas del sistema.
* **No se persiste nada del lado de ClickHouse**: los resultados leídos durante una sesión de solución de problemas —ya provengan de tablas del sistema, de la pila de monitorización o de tus logs— llegan a las herramientas del ingeniero para mostrarse, pero no se almacenan ni se exportan a la infraestructura de ClickHouse.

<h2 id="auditing">
  Auditoría
</h2>

La actividad de los ingenieros es visible para usted y queda auditada por ClickHouse:

* **Visible para el cliente (ClickHouse)**: cada consulta que ejecuta un ingeniero de ClickHouse en su instancia aparece en su propio `system.query_log`, incluido el texto de la consulta y la identidad del certificado. Puede auditarlo directamente desde su servicio de ClickHouse.
* **Visible para el cliente (infraestructura)**: `system.query_log` no puede mostrar las superficies de infraestructura mencionadas anteriormente. Las llamadas a la API de Kubernetes aparecen en los registros de auditoría de Kubernetes de su clúster, las llamadas a la API de la nube en su registro de auditoría en la nube, y las propias conexiones de Tailscale en sus registros de flujo allí donde los tenga habilitados. Consulte [Auditar el perímetro](/es/products/bring-your-own-cloud/reference/network-security#auditing-the-boundary) para saber dónde se encuentra cada uno de ellos en cada nube, incluidos cuáles están activados de forma predeterminada.
* **Del lado de ClickHouse**: el equipo de seguridad de ClickHouse registra y audita internamente todas las solicitudes de acceso, aprobaciones y conexiones de Tailscale.

<h2 id="future-controls">
  Controles futuros
</h2>

La aprobación gestionada por el cliente —es decir, que usted aprueba cada solicitud de acceso de un ingeniero antes de que entre en vigor— está en la hoja de ruta. Actualmente, la aprobación se gestiona mediante el proceso interno de escalado de ClickHouse.

<h2 id="related">
  Relacionado
</h2>

* [Seguridad de red de BYOC](/es/products/bring-your-own-cloud/reference/network-security) — cómo funcionan Tailscale y los límites de la red
* [Privilegios de BYOC](/es/products/bring-your-own-cloud/reference/privilege) — roles de IAM creados durante la configuración de BYOC