fixup

ydb/docs/ru/core/reference/configuration/index.md

@@ -366,49 +366,59 @@ default_access:
 
 #### Настройки административных и других привилегий
 
-`viewer_allowed_sids`, `monitoring_allowed_sids`, `administration_allowed_sids` — списки SID'ов, которым должны быть даны соответствующие привилегии.
+Управление доступом в {{ ydb-short-name }} реализуется двумя механизмами:
 
-[//]: # (TODO: wait for pull/9387, dinamic_node_registration to add info about `register_dynamic_node_allowed_sids`)
-
-Состояние кластера не ограничивается объектами схемы (базами, таблицами, топиками и т.д.), поэтому для доступа к состоянию кластера и состоянию его подсистем используется дополнительная иерархия привилегий, не связанная со схемными объектами и разрешениями на них (ACL).
+- ydb-правами на схемных объектах
+- дополнительными возможности или ограничениями по спискам разрешений
 
 [//]: # (TODO: добавить ссылку на описание схемных ACL, когда оно появится)
 
-Часть состояния кластера доступна без авторизации (например, [список узлов кластера](../embedded-ui/ydb-monitoring.md#список-узлов-node_list_page)). Этот базовый уровень возможностей расширяется дополнительными уровнями привилегий, задаваемыми списками `*_allowed_sids`.
+Оба механизма применяются одновременно: для конкретного субъекта действие оказывается доступно, если оба механизма его разрешают, и не доступно, если хотя бы один не разрешает.
+
+Списки разрешений используются для дополнительного расширения возможностей субъекта при работе со схемными объектами и для управления доступом в контексте, который не может быть связан с каким-либо схемным объектом.
 
 [//]: # (TODO: добавить ссылку на справку по viewer api и требуемым правам, когда она появится)
 
 #|
 || Параметр | Описание ||
 || `viewer_allowed_sids` | Список SID'ов с доступом уровня наблюдателя.
 
-Уровень наблюдателя даёт возможность просмотра всего состояния кластера и его подсистем через Web UI ([YDB Monitoring](../embedded-ui/ydb-monitoring.md)).
+Даёт возможность просмотра состояния системы через Web UI ([YDB Monitoring](../embedded-ui/ydb-monitoring.md)), без возможности делать изменения.
     ||
 || `monitoring_allowed_sids` | Список SID'ов с доступом уровня оператора.
 
-Уровень оператора даёт дополнительные возможности по просмотру и изменению состояния кластера. Например, выполнение бекапа или восстановление базы или выполнение YQL-запросов через Web UI.
+Даёт дополнительные возможности просмотра и выполнения действий, меняющих состояние системы. Например, выполнение бекапа или восстановление базы или выполнение YQL-запросов через Web UI.
     ||
 || `administration_allowed_sids` | Список SID'ов с доступом уровня администратора.
 
-Уровень администратора даёт максимальные возможности по изменению состояния системы.
+Даёт право на выполнение административных действий с базами или кластером.
     ||
 |#
 
+[//]: # (TODO: wait for pull/9387, dinamic_node_registration to add info about `register_dynamic_node_allowed_sids`)
+
 {% note warning %}
 
 По-умолчанию, все списки пустые.
 
-Пустой список `*_allowed_sids` разрешает доступ любому пользователю (включая анонимного пользователя). 
+Пустой список разрешает доступ любому пользователю (включая анонимного пользователя).
 
 Все три пустых списка дают возможности администратора любому пользователю системы.
 
 Для защищённого развёртывания {{ ydb-short-name }} важно заранее определить модель прав и прописать в списках соответствующие группы/роли.
 
 {% endnote %}
 
-SID'ы в списках могут быть групповыми и пользовательскими. Принадлежность пользователя к списку `*_allowed_sids` определяется по вхождению в список любой его группы (рекурсивно) или по прямому вхождению. Наиболее осмысленно включать в списки `*_allowed_sids` пользовательские группы и отдельные сервисные аккаунты, тогда наделение отдельных пользователей соответствующими привилегиями не будет требовать изменения общей конфигурации кластера.
+В списках могут перечисляться индивидуальные SID'ы пользователей или SID'ы пользовательских групп. Принадлежность пользователя к списку определяется по прямому вхождению или по вхождению в список любой его группы (рекурсивно).<br/>
+Наиболее осмысленно включать в списки `*_allowed_sids` пользовательские группы и отдельные сервисные аккаунты, тогда наделение индивидуальных пользователей соответствующими возможностями не будет требовать изменения общей конфигурации кластера.
+
+Списки разрешений можно воспринимать, как слои дополнительных разрешений.
+
+Субъект, не состоящий ни в одном списке разрешений, имеет базовую возможность по просмотру публично доступной информации о системе (например, может видеть [список баз на кластере](../embedded-ui/ydb-monitoring.md#tenant_list_page) или [список узлов кластера](../embedded-ui/ydb-monitoring.md#node_list_page)).
+
+Списки `viewer_allowed_sids`, `monitoring_allowed_sids`, `administration_allowed_sids` последовательно наращивают возможности субъекта. Максимальные возможности требуют включения во все три списка.
 
-`viewer_allowed_sids`, `monitoring_allowed_sids`, `administration_allowed_sids` представляют собой уровни расширения возможностей, по возрастанию. Принадлежность к `administration_allowed_sids` не означает автоматической принадлежности к `viewer_allowed_sids`. Для получения нужного объёма возможностей пользователь должен состоять во всех списках предыдущих уровней. Эту сборку возможностей должен обеспечивать администратор {{ ydb-short-name }} через конфигурацию `*_allowed_sids` списков.
+Присутствие в списке `monitoring_allowed_sids` или `administration_allowed_sids` без присутствия во `viewer_allowed_sids` не имеет смысла.
 
 Например: