> ## 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 к данным (BYOC)

> Какой доступ к данным клиентов имеют сотрудники ClickHouse в развертываниях BYOC

По умолчанию сотрудники ClickHouse не имеют доступа к вашим данным. Ваши данные в ClickHouse, включая все пользовательские таблицы и результаты запросов, остаются в вашем собственном облачном аккаунте. Ниже описаны единственные каналы, через которые ClickHouse взаимодействует с вашим развертыванием, — ни один из них не дает доступа к данным в клиентских таблицах.

<h2 id="routine-operations">
  Регулярные операции
</h2>

Control plane ClickHouse Cloud управляет вашим BYOC-развертыванием, не обращаясь к данным клиента. Компоненты, отправляющие данные в инфраструктуру, принадлежащую ClickHouse, передают только операционные метаданные:

| Компонент | Что попадает в инфраструктуру, принадлежащую ClickHouse |
| - | - |
| State exporter | Состояние сервиса и резервных копий (health, status — операционные события, а не содержимое резервных копий) в очередь, принадлежащую ClickHouse Cloud: `SQS` в AWS, Pub/Sub в GCP, Service Bus в Azure. |
| Billing scraper | Метрики CPU и памяти в бакет объектного хранилища, принадлежащий ClickHouse Cloud. |
| AlertManager | Оповещения о состоянии кластера в ClickHouse Cloud. |

Трафик запросов, содержимое таблиц и схемы по этим каналам не передаются никогда. Весь ваш набор данных мониторинга — стек Prometheus и Thanos, а также ваши журналы — остаётся в вашем собственном аккаунте; ограниченная телеметрия из таблицы выше — единственные данные обсервабилити, которые непрерывно экспортируются в системы, принадлежащие ClickHouse. Панели мониторинга ClickHouse, а при одобренной эскалации и его инженеры, могут дополнительно выполнять запросы к этому стеку и вашим журналам по месту через Tailscale, при этом на стороне ClickHouse ничего не сохраняется — см. [Доступ для устранения неполадок](#troubleshooting-access). Полный справочник входящих и исходящих потоков см. в разделе [сетевые границы](/ru/products/bring-your-own-cloud/reference/network-security#network-boundaries).

<h2 id="troubleshooting-access">
  Доступ для устранения неполадок
</h2>

Когда инженерам ClickHouse требуется диагностировать проблему в вашем развертывании, они запрашивают временный доступ через внутренний процесс эскалации и согласования. Одобренный доступ предоставляется с помощью сертификата с ограниченным сроком действия и осуществляется через [Tailscale](/ru/products/bring-your-own-cloud/reference/network-security#tailscale-private-network) — никогда через общедоступный интернет.

<h3 id="what-engineers-can-see">
  Что инженеры могут видеть
</h3>

В ClickHouse утверждённый доступ для устранения неполадок ограничен системными таблицами. Это включает:

* `system.query_log` — текст запроса и метаданные выполнения запросов к вашему сервису
* `system.tables`, `system.columns` и аналогичные системные таблицы — схема и метаданные
* Другие таблицы `system.*`, используемые для диагностики (например, части, мутации, реплики)

<h3 id="what-engineers-cant-see">
  Что инженеры не могут видеть
</h3>

Инженеры не могут просматривать пользовательские таблицы клиентов. В ClickHouse доступ ограничен только системными таблицами.

<h3 id="infrastructure-diagnostics">
  Диагностика инфраструктуры
</h3>

Тот же процесс эскалации с обязательным одобрением может отдельно предоставить ограниченный по времени доступ к инфраструктурным компонентам через Tailscale: к API-серверу Kubernetes, а также к внутрикластерному стеку мониторинга и журналам. Это отдельный контур, не связанный с описанным выше доступом к 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 — в flow-логах, если вы их включили. См. [Аудит границы](/ru/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](/ru/products/bring-your-own-cloud/reference/network-security) — как работают Tailscale и сетевые границы
* [Привилегия BYOC](/ru/products/bring-your-own-cloud/reference/privilege) — роли IAM, создаваемые при настройке BYOC