Перейти к содержанию

Security и контроль доступа

Результат

Вы удержите project access, connectors, MCP credentials, exports и admin settings внутри нужной tenant boundary.

Что потребуется

  • Определите owner проекта и ответственного за каждый connector.
  • Новую интеграцию или write-back policy сначала проверяйте в отдельном test project.
  • Не размещайте production secrets, access tokens, API keys, customer data и internal service URLs в документации, скриншотах, tickets или chat.

Проверить границу данных

Threadory ограничивает knowledge, activity, approvals, exports, API keys и MCP connections одним проектом. API проверяет membership и фильтрует данные по выбранному project.

  1. В project switcher проверьте организацию и проект.
  2. Откройте Settings → Members и проверьте каждую роль.
  3. Удалите больше не нужный доступ.
  4. Сохраняйте хотя бы одного owner: до удаления или понижения последнего owner назначьте замену.
  5. Используйте разные projects, если данные или доступ нельзя разделять.

Organization access — first-class org_membership (ADR-0006). Наличие роли в organization не означает той же роли во всех projects: доступ к данным по-прежнему через project membership.

Применить least privilege

Выдавайте минимальную роль для задачи:

  • Viewer — чтение project data и governance-вкладок уровня viewer;
  • Member — вклад в проект и запрос project actions;
  • Admin — connectors, settings, API keys, exports и approvals;
  • Owner — изменение ролей, organization access controls и destructive settings проекта или организации.

Owner может открыть Settings → Organization → Access control и установить minimum role для Cost, Audit Log, Prompts, LLM и API Keys. Для Cost, Audit Log и API Keys есть отдельная server-side проверка чтения. Считайте видимость вкладки навигацией, а не единственной security boundary; изменение settings дополнительно ограничено server-enforced role.

Защитить identity connector

  1. Выдавайте только scopes из connector guide и матрицы интеграций.
  2. Используйте отдельную service identity, если source это поддерживает.
  3. Передавайте OAuth credentials и webhook secrets через secret flow Threadory, а не через free-text fields.
  4. После подключения выполните read-only или low-risk проверку из guide.
  5. Перед disconnect или rotation проверьте pending approvals и automations, зависящие от identity.
  6. После проверки замены отзовите старый credential во внешней системе.

Отключение source останавливает будущий доступ, но само по себе не доказывает удаление уже синхронизированных entities, audit records или exports. Для data lifecycle используйте документированные export и retention.

Защитить MCP и API keys

  1. Для интерактивного MCP-клиента человека предпочитайте OAuth.
  2. Project API key создавайте только для именованной headless-интеграции.
  3. Скопируйте plaintext один раз в разрешённый secret store.
  4. Не добавляйте key в MCP URL, Git, screenshots или prompts.
  5. Проверяйте Last used в Settings → API Keys.
  6. Немедленно отзывайте неиспользуемые или подозрительные keys и заменяйте их в интеграции.

API key привязан к одному проекту. OAuth-доступ MCP следует текущим membership и role пользователя.

Отключить пользователя или интеграцию

  1. Определите затронутые projects, connectors, API keys и pending approvals.
  2. Выгрузите необходимые records до destructive retention или cleanup.
  3. Отзовите именованные API keys и credentials во внешней системе.
  4. Удалите membership или понизьте роль.
  5. Отключите automatic write-back без ответственного reviewer.
  6. Проверьте, что старые credentials получают 401 или 403, а действующие пользователи сохранили доступ.
  7. Запишите изменение в утверждённый change log организации.

Реагировать на подозрение об утечке

  1. Сначала отзовите или ротируйте credential.
  2. Не вставляйте утёкшее значение в incident ticket.
  3. Выполните поиск по actor и time в Audit Log и сопоставьте с Activity.
  4. Проверьте audit history внешней системы.
  5. Создавайте замену только после проверки project и minimum access.
  6. Эскалируйте platform operator при подозрении на cross-project access, неизвестную активность или отсутствие audit evidence.

Как проверить результат

  • Удалённый user не может открыть project.
  • Отозванный API key сразу перестаёт работать.
  • Viewer может читать, но не решать approvals и не менять settings.
  • Connector и MCP возвращают данные только своего project.
  • Нужные audit и export evidence сохранены в разрешённом месте.

Частые проблемы

Симптом Вероятная причина Что сделать
User видит чувствительную settings tab Owner установил низкую minimum role Проверьте Organization → Access control и role matrix
API скрытой вкладки ведёт себя не так, как ожидалось Tab visibility и endpoint authorization — разные controls Проверьте запрос с нужной ролью и сообщите о server-side gap
API key нельзя восстановить Plaintext намеренно показывается один раз Отзовите key и создайте замену
После disconnect остались historical knowledge Удаление connector не означает data deletion Примените утверждённый export и retention process
После rotation перестал работать write-back Connector использует старую identity или потерял scopes Переподключите, проверьте minimum scopes и безопасное действие
Данные проекта появились не в том context Был активен другой project или подозревается boundary defect Остановите работу, сохраните evidence и эскалируйте без копирования customer data в ticket

Следующий шаг

Проверьте members и roles, затем настройте audit, export и retention.