Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Начните с модели угроз и списка документов
Представим пространство проекта, где лежат общие инструкции, коммерческие предложения и материалы внешнего подрядчика. Опасность состоит в том, что одинаковое дерево создаёт ощущение одинаковых прав. Составьте список особенно чувствительных страниц, включая вложения и дочерние материалы. Для каждой определите допустимую аудиторию и владельца решения о доступе. Отдельно перечислите подрядчиков, временных сотрудников и сервисные интеграции. Не начинайте с массового снятия ограничений ради удобства: сначала зафиксируйте ожидаемый результат. Пилот можно провести на одном разделе, где последствия ошибки понятны и владелец доступен для быстрой проверки.
Разберите уровни разрешений
В Confluence разрешения пространства и ограничения конкретного содержимого взаимодействуют, поэтому добавление человека к странице не следует воспринимать как универсальную выдачу всех необходимых прав. Ограничения просмотра родительского содержимого могут влиять на доступ к потомкам. Сначала проверьте доступ пользователя к приложению и пространству, затем цепочку родителей, затем саму страницу. Используйте актуальную документацию вашего интерфейса: управление ролями может различаться между сайтами. Для аудита полезна таблица с четырьмя колонками: пользователь, группа, ожидаемое действие и фактический результат. В ней должно быть различие между чтением, редактированием и управлением ограничениями.
Настройте группы по рабочим ролям
Согласуйте несколько понятных групп: читатели проекта, редакторы инструкций и внешняя команда. Названия должны объяснять назначение, а описание — владельца и порядок включения. Избегайте персональных разрешений без срока пересмотра: через несколько месяцев трудно понять, почему конкретному бывшему участнику сохранили доступ. Сначала добавьте нужную группу и проверьте её действие, затем удаляйте устаревшее персональное исключение. Зафиксируйте исходные настройки скриншотами или таблицей, не включая в неё секретное содержимое страниц. Одно изменение за итерацию позволяет установить причину неожиданного отказа. Массовая перенастройка одновременно на нескольких уровнях сильно усложняет диагностику.
Проведите позитивные и негативные проверки
Нужны отдельные тестовые пользователи с реалистичными ролями. Внутренний читатель должен открыть общую инструкцию, подрядчик — согласованный раздел, посторонний сотрудник — получить отказ на чувствительном материале. Проверьте прямую ссылку, поиск, переход через родителя и доступ к вложениям. Используйте отдельный браузерный профиль, чтобы администраторская сессия не исказила результат. Для отрицательной проверки важен именно отказ, а не отсутствие страницы в меню. Запишите точный URL, действие, роль и время. Проверку выполните повторно после перемещения страницы, изменения состава групп или передачи проекта другой команде.
Отдельно рассмотрите публичные каналы
Проверьте анонимный доступ, внешнюю публикацию и любые применяемые на вашем сайте механизмы предоставления материалов за пределами обычного пространства. Не предполагайте, что отсутствие подрядчика в одной группе автоматически закрывает все способы чтения. Найдите страницы, которые команда намеренно делает доступными клиентам, и назначьте им отдельного владельца публикации. Для таких материалов нужен редакционный контроль: нет ли клиентских идентификаторов, внутренних адресов и фрагментов конфигурации. Изменение доступа не удаляет уже скачанные копии. Если чувствительные сведения были опубликованы, потребуется разбор инцидента и замена раскрытых секретов, а не только восстановление ограничений.
Подготовьте откат и периодический пересмотр
До изменения назначьте человека, способного восстановить настройки пространства, и сохраните исходный состав групп. При неожиданном отказе сначала сравните реальные группы пользователя, затем ограничения предков; не выдавайте широкие права всему пространству как временный обход. После исправления повторите всю матрицу, включая отрицательные случаи. В рабочий календарь добавьте пересмотр доступа при уходе подрядчика и смене владельца проекта. Результатом аудита должна стать небольшая понятная схема с исключениями и ответственными. Документируйте основания исключений и дату следующей проверки. Тогда следующий администратор сможет отличить намеренное ограничение от накопленной случайности.
Матрица проверки для подрядчика
Для отдельной проверки подготовьте три безвредные страницы: общедоступную проектной команде, доступную только внутренним сотрудникам и разрешённую подрядчику. Укажите на каждой, какое поведение ожидается, не помещая туда реальную конфиденциальную информацию. Затем сравните результаты для внутреннего читателя, внешнего участника и пользователя вне проекта. После этого переместите разрешённую страницу под другого родителя в пилотном разделе и повторите проверки. Такой эксперимент показывает команде, почему перенос содержимого должен сопровождаться контролем доступа. Зафиксируйте не только факт чтения, но и доступность редактирования и смены ограничений. Если фактическое поведение отличается от согласованной модели, остановите перенос настоящих материалов. Выясните влияние групп и родительской структуры, верните исходное положение тестовой страницы и повторите упражнение. Сохраняйте результаты вместе с заявкой на изменение, чтобы следующий администратор мог воспроизвести контроль.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу