мелкие правки

src/PaaS/PostgreSQL/cluster_parameter.md

@@ -0,0 +1,81 @@
+# О разделе
+
+Данный раздел содержит описание технических параметров кластера PostgreSQL и порядок их первичной конфигурации.
+
+Настройка указанных параметров выполняется администратором облачного провайдера на этапе развёртывания сервиса. Пользователь не имеет прямого доступа к их самостоятельной установке.
+
+Перед созданием кластера клиент предоставляет перечень требуемых параметров менеджеру. Администратор облачного провайдера выполняет конфигурацию в соответствии с согласованными требованиями.
+
+## Выбор типа и размера дискового хранилища
+
+Производительность базы данных напрямую зависит от скорости, с которой она может читать и записывать данные на диск. При заказе кластера необходимо выбрать тип дискового хранилища, который определит максимальную скорость работы (IOPS) и время отклика.
+
+**IOPS (Input/Output Operations Per Second)** — количество операций чтения или записи, которые диск может выполнить за секунду. Чем выше этот показатель, тем быстрее база данных обрабатывает запросы.
+
+## Доступные типы хранилищ:
+
+| Название       | Лимит IOPS         |
+| -------------- | ------------------ |
+| **Fast SAS**   | до 2 IOPS на 1 ГБ  |
+| **SSD**        | до 5 IOPS на 1 ГБ  |
+| **Fast SSD**   | до 10 IOPS на 1 ГБ |
+| **Ultra NVMe** | до 25 IOPS на 1 ГБ |
+
+::: warning Примечание
+
+После выбора типа диска необходимо указать объем дискового хранилища, который будет выделен под данные кластера PostgreSQL. Минимальный объем - 50 ГБ.
+
+:::
+
+## Конфигурация вычислительных ресурсов
+
+В данном разделе определяются вычислительные мощности кластера: процессорные ресурсы, оперативная память и количество серверов (нод), из которых будет состоять кластер PostgreSQL.
+
+### Количество нод в кластере
+
+Количество нод определяет отказоустойчивость кластера и возможность распределять запросы на чтение между репликами. Чем больше нод, тем выше надёжность и производительность операций чтения.
+
+Количество нод выбирается в диапазоне **от 1 до 5**.
+
+### Процессор (CPU)
+
+Процессор — это вычислительная мощность, выделяемая каждой ноде кластера. Количество vCPU определяет, насколько быстро база данных сможет:
+
+- обрабатывать запросы;
+- выполнять сложные операции (сортировки, объединения таблиц);
+- обслуживать одновременные подключения.
+
+Доступный диапазон: **от 2 до 24 vCPU** на ноду.
+
+### Оперативная память (RAM)
+
+Оперативная память — один из ключевых ресурсов для производительности базы данных. Данные, помещающиеся в RAM, обрабатываются максимально быстро, без обращения к диску.
+
+Доступный диапазон: **от 4 до 768 ГБ RAM** на ноду.
+
+### Доступ в интернет
+
+При заказе сервиса можно выбрать пропускную способность канала связи, через который будет осуществляться доступ к кластеру PostgreSQL из сети интернет.
+
+**Доступные варианты скорости:**
+- 50 Мбит/с;
+- 100 Мбит/с;
+- 200 Мбит/с;
+- 300 Мбит/с;
+- 400 Мбит/с;
+- 500 Мбит/с;
+- 1000 Мбит/с (1 Гбит/с).
+
+::: warning Примечание
+
+Для выбранного канала предоставляется статический белый IP-адрес.
+
+:::
+
+## Сетевой доступ к кластеру
+
+Для организации защищенного подключения к кластеру Kafka доступны стандартные механизмы, используемые во всех сервисах платформы:
+- **IPsec-подключение** - организация защищенного туннеля между инфраструктурой и кластером PostgreSQL. Подробнее см. раздел IPsec;
+- **Interconnection** - прямое сетевое соединение между сервисами внутри платформы без выхода в интернет. Подробнее см. раздел Interconnection.
+
+Выбор конкретного способа подключения зависит от архитектуры приложений и требований к безопасности.

src/PaaS/PostgreSQL/user_capabilities.md

@@ -0,0 +1,203 @@
+# Создание сервиса Cloud PostgreSQL
+
+Данный раздел описывает права, которые предоставляются пользователю PostgreSQL при создании сервиса **Cloud PostgreSQ**L**, а также перечень административных операций, доступных ему для самостоятельного выполнения.
+
+При развертывании сервиса автоматически создаётся пользователь базы данных с преднастроенными атрибутами и привилегиями. Эти права позволяют заказчику самостоятельно управлять своими базами данных, ролями и пользователями в рамках созданного экземпляра PostgreSQL.
+
+## Общая информация о пользователе
+
+При инициализации сервиса автоматически создаётся пользователь:
+
+```nginx
+client 
+```
+
+Данный пользователь является основной учётной записью для административной работы в рамках предоставленного экземпляра PostgreSQL. Он предназначен для самостоятельного управления базами данных, ролями и правами доступа в пределах выданных привилегий.
+
+## Выданные права и ограничения
+
+Пользователю `client` назначается набор атрибутов и привилегий, позволяющих выполнять административные операции в рамках своего экземпляра базы данных.
+
+### Атрибуты роли
+
+Пользователь создаётся со следующими атрибутами:
+- `CREATEDB` — разрешено создание и удаление баз данных;
+- `CREATEROLE` — разрешено создание ролей и пользователей, а также управление их.
+
+Атрибут `SUPERUSER` пользователю не предоставляется. Соответственно, доступ к системным операциям уровня кластера и настройкам сервера отсутствует.
+
+### Права на системную базу postgres:
+
+К стандартной базе данных `postgres` пользователю предоставлено только право подключения:
+- `CONNECT`
+Иные привилегии (создание объектов, изменение схем и т.д.) на данную базу не выдаются.
+
+### Мониторинг и системные представления:
+
+Для выполнения базовых задач мониторинга пользователю дополнительно предоставлены:
+- членство в роли `pg_monitor`;
+- право `SELECT` на системное представление:
+```sql
+pg_catalog.pg_stat_replication
+```
+
+Доступ к системной информации предоставляется исключительно в режиме чтения. Изменение системных представлений и параметров сервера недоступно.
+
+## Обязательная смена пароля
+
+После первого подключения к базе данных пользователь `client` обязан выполнить смену пароля.
+Смена пароля может быть выполнена:
+- в открытом виде (с передачей нового значения пароля);
+- с указанием заранее сгенерированного хэша.
+
+На сервере используется алгоритм шифрования паролей:
+
+```
+scram-sha-256
+```
+
+При использовании SCRAM применяется следующий формат хэша:
+
+```
+$<iterations>:<salt>$<storedkey>:<serverkey>
+```
+
+### Пример смены пароля в открытом виде
+
+```sql
+ALTER USER client WITH PASSWORD 'new_strong_password';
+```
+
+### Пример смены пароля с указанием хэша
+
+```sql
+ALTER USER client WITH ENCRYPTED PASSWORD '$4096:...';
+```
+
+Рекомендуется использовать сложный уникальный пароль, соответствующий требованиям информационной безопасности, и хранить его в защищённом хранилище.
+
+## Создание новой базы данных
+
+Пользователь `client` имеет право создавать новые базы данных в рамках своего экземпляра PostgreSQL.
+
+### Пример создания базы данных
+
+Для создания базы данных используется стандартная команда:
+
+```sql
+CREATE DATABASE app_db;
+```
+
+Если необходимо назначить владельца базы данных, можно указать соответствующего пользователя. По умолчанию владельцем создаваемой базы данных является пользователь, который её создает.
+
+### Пример создания базы данных с указанием владельца
+
+```sql
+CREATE DATABASE app_db OWNER client;
+```
+
+В этом примере база данных `app_db` будет принадлежать пользователю `client`. Пользователь, указанный как владелец, будет иметь полный контроль над базой данных, включая права на её удаление и изменение.
+
+## Создание пользователей и ролей
+
+Пользователь `client` имеет право создавать новые роли и пользователей для приложений, а также управлять их правами доступа.
+
+### Создание роли без логина
+
+Если требуется создать роль, которая не будет иметь возможности входа в базу данных (например, для организации прав доступа), можно использовать команду:
+
+```sql
+CREATE ROLE app_role;
+```
+
+### Создание пользователя с паролем
+
+Для создания пользователя с паролем используется команда:
+
+```sql
+CREATE USER app_user WITH PASSWORD 'app_password';
+```
+
+После этого новый пользователь `app_user` будет иметь возможность входа в базу данных, используя указанный пароль.
+
+### Назначение роли пользователю
+
+Для назначения роли пользователю используется команда `GRANT`. Это позволяет управлять правами пользователя в рамках определённой роли:
+
+```sql
+GRANT app_role TO app_user;
+```
+
+После выполнения этой команды пользователь `app_user` станет членом роли `app_role`, и будет наследовать все права, связанные с этой ролью.
+
+### Передача владельца базы данных
+
+Если необходимо передать право владения базой данных другому пользователю, это можно сделать с помощью следующей команды:
+
+```sql
+ALTER DATABASE app_db OWNER TO app_user;
+```
+
+Теперь база данных `app_db` будет принадлежать пользователю `app_user`, и он будет иметь полный контроль над ней.
+
+### Управление правами доступа
+
+После создания пользователей и ролей необходимо назначить им соответствующие права доступа.
+
+### Выдача прав на подключение к базе данных
+
+Для того чтобы пользователь мог подключаться к базе данных, нужно предоставить ему соответствующие права:
+
+```sql
+GRANT CONNECT ON DATABASE app_db TO app_user;
+```
+
+Эта команда разрешает пользователю `app_user` подключаться к базе данных `app_db`.
+
+### Права на схему public
+
+Для предоставления пользователю прав на использование схемы `public` можно выполнить следующую команду:
+
+```sql
+GRANT USAGE, CREATE ON SCHEMA public TO app_user;
+```
+
+Эти права позволяют пользователю `app_user` использовать объекты в схеме `public`, а также создавать новые объекты внутри неё.
+
+### Права на существующие таблицы
+
+Чтобы предоставить пользователю доступ к существующим таблицам в схеме `public`, можно использовать команду:
+
+```sql
+GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_user;
+```
+
+Эта команда позволяет пользователю `app_user` выполнять операции чтения, вставки, обновления и удаления данных в существующих таблицах схемы `public`.
+
+### Права на будущие таблицы
+
+Если необходимо автоматически предоставить пользователю права на новые таблицы, создаваемые в схеме `public`, используйте команду:
+
+```sql
+ALTER DEFAULT PRIVILEGES IN SCHEMA public
+GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_user;
+```
+
+Эта команда обеспечит, что все будущие таблицы, создаваемые в схеме `public`, будут автоматически иметь права для пользователя `app_user` на чтение, вставку, обновление и удаление данных.
+
+## Мониторинг репликации
+
+Пользователь `client` имеет доступ к системным представлениям для мониторинга состояния репликации в кластере PostgreSQL.
+
+### Просмотр состояния репликации
+
+Для того чтобы просмотреть текущий статус репликации, пользователь может выполнить запрос к системному представлению:
+
+``` SQL
+SELECT * FROM pg_stat_replication;
+```
+Этот запрос возвращает информацию о всех репликах, подключённых к основному (primary) серверу.
+
+### Ограничения доступа
+
+Пользователь `client` имеет доступ к данным в представлении `pg_stat_replication` только в режиме **read-only**. Это означает, что он может просматривать состояние репликации, но не может изменять или вмешиваться в процесс репликации.