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