[Документация Yandex Cloud](../../index.md) > [Yandex Managed Service for Sharded PostgreSQL](../index.md) > Вопросы и ответы > Безопасность

# Безопасность в Managed Service for Sharded PostgreSQL

* [Как обеспечивается безопасность данных?](#data-security)

* [Не утекают ли учетные данные через роутер?](#router-security)

* [Как настроить резервное копирование?](#how-to-set-up-backups)

* [Как обеспечить высокую доступность?](#high-availability)

* [Что происходит при перегрузках?](#overload-behaviour)

* [Как обрабатывается отмена запросов?](#cancel-query-processing)

* [Есть ли риски дублирования запросов при использовании балансировщика перед роутерами?](#query-duplication)

* [Как ограничить доступ к административной консоли?](#restrict-access-to-admin-console)

#### Как обеспечивается безопасность данных? {#data-security}

Sharded PostgreSQL хранит только метаданные о расположении данных. За безопасность данных отвечает сервис [Managed Service for PostgreSQL](../../managed-postgresql/index.md), при этом:

* Поддерживается шифрование трафика — TLS 1.3 для всех соединений (клиент ↔ роутер ↔ шард).
* Доступен аудит — [логи доступа](../at-ref.md) хранятся в сервисе [Yandex Audit Trails](../../audit-trails/index.md) в течение 30 дней. [Подробнее о просмотре логов в кластере Managed Service for Sharded PostgreSQL](../operations/cluster-logs.md).

#### Не утекают ли учетные данные через роутер? {#router-security}

Нет, данные не утекают. Риски аналогичны использованию пулера подключений (например, [Odyssey](https://yandex.ru/dev/odyssey/)). Данные передаются через Sharded PostgreSQL, но практики безопасности соответствуют [стандартам Yandex Cloud](../../security/standarts.md).

#### Как настроить резервное копирование? {#how-to-set-up-backups}

Резервное копирование запускается автоматически для всех задействованных кластеров. Опционально вы можете задать время начала резервного копирования и выбрать срок хранения резервных копий. [Подробнее о настройке резервного копирования в Managed Service for Sharded PostgreSQL](../operations/cluster-backups.md).

#### Как обеспечить высокую доступность? {#high-availability}

Чтобы обеспечить высокую доступность кластера Managed Service for Sharded PostgreSQL:

* Создавайте шарды таким образом, чтобы каждый шард (то есть кластер Managed Service for PostgreSQL) включал не менее трех хостов (мастер и реплики), расположенных в разных зонах доступности.
* Для кластеров Managed Service for Sharded PostgreSQL со стандартным шардированием создайте не менее трех хостов `INFRA` в разных зонах доступности.
* Для кластеров Managed Service for Sharded PostgreSQL с расширенным шардированием создайте не менее трех хостов `COORDINATOR` и трех хостов `ROUTER` в разных зонах доступности.

#### Что происходит при перегрузках? {#overload-behaviour}

Перегруженная реплика становится недоступной, и кластер перестает отправлять к ней запросы до возобновления ее работы. 

Например, кластер получает 95% запросов на запись и 5% на чтение. Если параметр конфигурации роутера `default_target_session_attrs = read-only`, то запросы на чтение равномерно распределяются между репликами. Если в какой-то момент реплика становится недоступной (`SELECT pg_is_in_recovery();` не выполняется в заданное время), сервис перестает отправлять запросы к реплике и проверяет ее статус. Как только реплика снова отвечает, отправка запросов к ней возобновляется.

#### Как обрабатывается отмена запросов? {#cancel-query-processing}

Приложение прерывает текущее соединение с роутером, открывает новое и отправляет роутеру cancel-сообщение с идентификатором запроса. Роутер получает cancel-сообщение и передает его на шард, которому адресован запрос.

{% note tip %}

Отмена запроса вызывает переподключения и повышение нагрузки на TLS handshake, поэтому не рекомендуется использовать таймаут запросов менее 100 мс.

{% endnote %}

#### Есть ли риски дублирования запросов при использовании балансировщика перед роутерами? {#query-duplication}

Да. Если клиент разрывает соединение и балансировщик повторяет запрос, Sharded PostgreSQL обработает его как новый, что может привести к дублированию (например, для `INSERT`). Рекомендуется использовать идемпотентные операции или реализовать механизм дедупликации на уровне приложения.

#### Как ограничить доступ к административной консоли? {#restrict-access-to-admin-console}

Доступ к административной консоли ограничен по умолчанию. [Подключиться](../operations/connect.md) к консоли можно только с TLS при помощи пароля.

Пароль для доступа к административной консоли задается при [создании кластера](../operations/cluster-create.md). При необходимости вы можете [изменить пароль](../operations/cluster-update.md) на работающем кластере.