Перейти к основному содержимому

Сила тенантной изоляции

Версия: 1.0 Дата: 26.04.2026 Статус: Готов к обсуждению

Назначение документа​

Документ определяет силу тенантной изоляции (multi-tenant isolation strength) Vitiana — каноничную модель уровней изоляции тенантов с явными триггерами перехода, защиту межтенантных утечек, аудит, операционные процедуры реакции на инциденты, поддержку требований к локализации данных и регуляторных обязательств.

Включает:

  • Каноничную модель: IsolationLevel, TenantIsolationProfile, IsolationBoundaryCheck, CrossTenantAccess, IsolationIncident.
  • Три каноничных уровня изоляции: логическая (logical) / выделенный compute (dedicated_compute) / выделенная инфраструктура (dedicated_infrastructure).
  • Шесть измерений изоляции: данные / вычисления / сеть / хранилище / идентичность / журнал.
  • Триггеры перехода между уровнями.
  • Защиту от межтенантных утечек — multi-layer (база данных через RLS, программный интерфейс через scope, кеш через namespace, логи через redaction).
  • Контролируемую межтенантную видимость для команды платформы — разрешения, журнал, лимиты.
  • Аудит и compliance-журнал доступа.
  • Локализацию данных по юрисдикциям.
  • Реакцию на инциденты изоляции.
  • Метрики и наблюдаемость.
  • Фазы развёртывания.

Документ читается после:

В корневых документах зафиксированы базовые принципы изоляции (Strong Tenant Isolation как закон). Этот документ описывает уровни силы изоляции — от базовой логической до полной выделенной инфраструктуры — с правилами выбора уровня для конкретного тенанта.

Тенантная изоляция — критический архитектурный принцип платформы. Утечка данных между тенантами — это:

  • Регуляторное нарушение по общему регулированию защиты данных.
  • Прямой удар по доверию партнёров (особенно корпоративных).
  • Потенциальный экзистенциальный риск для платформы.

При этом — уровень изоляции должен соответствовать тарифу и потребностям тенанта. Применять полную выделенную инфраструктуру для каждого тенанта — экономически нереализуемо. Применять только логическую для всех — недостаточно для крупных корпоративных партнёров с регуляторными требованиями.

Сила изоляции — это коммерческий и регуляторный продукт, не одинаковая для всех.

Реальное состояние реализации (home-to-go-api): таблицы usr покрывают базовых users + organizations, но Tenant сущность как явный boundary не реализован. Целевое состояние — единая каноничная модель, описанная этим документом.

Правило 00000 (платформа главенствует над поставщиками) применяется здесь напрямую: уровень изоляции — выбор платформы, не наследие от конкретного партнёра. Партнёр получает уровень в соответствии со своим тарифом и регуляторными требованиями; тенант не диктует «свою» модель изоляции.

Главное решение​

Сила тенантной изоляции — каноничная архитектурная сущность с тремя уровнями, явными триггерами перехода и многослойной защитой.

Это означает:

  • Три каноничных уровня — logical / dedicated_compute / dedicated_infrastructure. Каждый тенант имеет назначенный уровень.
  • Шесть измерений изоляции — данные / вычисления / сеть / хранилище / идентичность / журнал. Уровень изоляции применяется в каждом измерении.
  • Многослойная защита — изоляция реализована одновременно на нескольких уровнях (БД через row-level security, программный интерфейс через scope, кеш через namespace, журналы через redaction). Утечка одного слоя не приводит к компрометации.
  • Контролируемая межтенантная видимость — только для команды платформы, только через явные роли, всегда с журналом аудита.
  • Регулярный audit изоляции — автоматические проверки границ, ручное ревью.
  • Локализация данных — для тенантов с регуляторными требованиями (например, операторов в Казахстане с местным законодательством о персональных данных) — данные физически в нужном регионе.
  • Реакция на инциденты — каноничная процедура с эскалацией при подозрении на утечку.
  • Связь с тарифом — уровень изоляции зависит от тарифа (Enterprise — dedicated, Professional — strong logical, ниже — логический baseline).

Каноничные сущности (углубление существующих)​

Уже зафиксированное в tenancy-and-identity.md​

  • Сущность Tenant как boundary of isolation.
  • Базовые классы: platform_internal_tenant, agency_tenant, partner_tenant, dedicated_embedded_tenant.
  • Две модели изоляции: Strong Tenant Isolation и Controlled Cross-Tenant Visibility.

Этот документ расширяет через дополнительные сущности.

Новые сущности​

IsolationLevel — уровень изоляции​

Сущность, представляющая именованный уровень изоляции в каталоге.

{
  level_id: UUID,
  level_key: enum,
  level_name: string,
  description: string,
  data_isolation_class: enum,
  compute_isolation_class: enum,
  network_isolation_class: enum,
  storage_isolation_class: enum,
  identity_isolation_class: enum,
  log_isolation_class: enum,
  applicable_tenant_classes: array,
  applicable_tariff_levels: array,
  cost_class: enum,
  applicable_phase: integer,
  is_active: boolean
}

Поля:

  • level_key — logical / dedicated_compute / dedicated_infrastructure.
  • data_isolation_class — класс изоляции данных (shared_with_rls — общая БД с row-level security; shared_schema — общая схема с tenant_id; dedicated_schema_in_shared_db — отдельная схема внутри общей БД; dedicated_database — выделенная БД; dedicated_database_in_dedicated_region — выделенная БД в выделенном регионе).
  • compute_isolation_class — класс изоляции вычислений (shared_pool — общий pool; dedicated_pod_in_shared_cluster — выделенный pod; dedicated_node_in_shared_cluster — выделенная нода; dedicated_cluster — отдельный кластер).
  • network_isolation_class — класс изоляции сети (shared_namespace — общее пространство; dedicated_namespace — выделенное; dedicated_vpc — выделенная виртуальная частная сеть).
  • storage_isolation_class — класс изоляции хранилища (shared_bucket_with_prefix — общий bucket с префиксом; dedicated_bucket — выделенный; dedicated_bucket_in_region — выделенный в регионе).
  • identity_isolation_class — класс изоляции идентичности (shared_realm — общий realm; dedicated_realm — выделенный; federated_with_partner_idp — федеративный с партнёрским провайдером идентификации).
  • log_isolation_class — класс изоляции журналов (tagged_in_shared_log — теги в общем; dedicated_log_stream — выделенный поток; dedicated_log_destination — журналы в собственное хранилище партнёра).

TenantIsolationProfile — профиль изоляции тенанта​

Сущность, представляющая назначенный уровень изоляции для конкретного тенанта.

{
  profile_id: UUID,
  tenant_id: UUID,
  current_level_id: UUID,
  effective_data_residency_region: string,
  effective_compliance_obligations: array,
  custom_overrides: object,
  applied_at: timestamp,
  approved_by: string,
  next_review_at: timestamp,
  audit_journal: array
}

Поля:

  • current_level_id — текущий уровень изоляции тенанта.
  • effective_data_residency_region — фактический регион хранения данных тенанта (eu_west / ua_local / kz_local / gb_local / multi_region).
  • effective_compliance_obligations — фактические compliance-обязательства (например, gdpr_eu_dpa_required, pci_dss_attestation_required, local_data_protection_kz).
  • custom_overrides — особые правила, отличающиеся от стандартного уровня (для корпоративных контрактов).
  • approved_by — кто одобрил уровень.
  • next_review_at — момент следующего ревью (типично раз в год).
  • audit_journal — каноничный журнал изменений уровня.

IsolationBoundaryCheck — проверка границы изоляции​

Сущность, представляющая формальную проверку, что граница изоляции конкретного тенанта не нарушена.

{
  check_id: UUID,
  tenant_id: UUID,
  check_class: enum,
  check_logic: object,
  result: enum,
  detected_at: timestamp,
  resolved_at: timestamp,
  severity: enum,
  affected_resource_type: enum,
  affected_resource_count: integer,
  remediation: enum
}

Поля:

  • check_class — класс проверки:

    • cross_tenant_query_attempt — попытка запроса данных другого тенанта.
    • cross_tenant_cache_leak — обнаружение данных другого тенанта в общем кеше.
    • cross_tenant_log_leak — данные тенанта в общем журнале без redaction.
    • dedicated_resource_violation — общий ресурс используется тенантом с уровнем dedicated.
    • data_residency_violation — данные тенанта оказались вне разрешённого региона.
    • compute_pool_assignment_drift — тенант с dedicated compute оказался на общем pool.
    • identity_realm_misalignment — пользователь подключился через неправильный realm.

  • severity — серьёзность (critical — критическая утечка с финансовыми/регуляторными последствиями; high — существенное нарушение; medium — нарушение конфигурации без утечки; low — несоответствие, требующее правки).

  • remediation — каким образом устранено (automatic_block — автоматическая блокировка операции; data_quarantined — данные изолированы для расследования; manual_correction — ручная корректировка; escalated_to_security_team — эскалация команде безопасности).

CrossTenantAccess — межтенантный доступ​

Сущность, представляющая разрешённый и журналируемый доступ команды платформы к данным конкретного тенанта.

{
  access_id: UUID,
  accessed_tenant_id: UUID,
  accessor_user_id: UUID,
  accessor_role: enum,
  access_purpose: enum,
  access_justification: string,
  authorized_resources: array,
  approval_chain: array,
  granted_at: timestamp,
  expires_at: timestamp,
  revoked_at: timestamp,
  audit_journal: array
}

Поля:

  • access_purpose — каноничная цель (incident_investigation / support_ticket / compliance_audit / bug_reproduction / security_investigation / legal_request — как требование регулятора).
  • access_justification — текстовое обоснование (для аудита).
  • approval_chain — цепочка одобрений (для критических доступов — несколько уровней).
  • expires_at — обязательное ограничение по времени (типично от часа до суток в зависимости от цели).
  • audit_journal — журнал всех действий внутри доступа.

IsolationIncident — инцидент изоляции​

Сущность, представляющая зарегистрированный инцидент, потенциально нарушивший границы изоляции.

{
  incident_id: UUID,
  affected_tenant_ids: array,
  incident_class: enum,
  detection_source: enum,
  detected_at: timestamp,
  contained_at: timestamp,
  resolved_at: timestamp,
  severity: enum,
  scope: object,
  immediate_actions_taken: array,
  root_cause_analysis: object,
  notification_status: object,
  regulatory_notification_required: boolean,
  regulatory_notification_completed_at: timestamp,
  affected_records_count: integer,
  affected_data_classes: array
}

Поля:

  • incident_class — класс инцидента (data_leak_confirmed / data_leak_suspected / unauthorized_access / dedicated_resource_violation / data_residency_violation).
  • notification_status — состояние уведомлений (тенантам, регулятору).
  • regulatory_notification_required — требуется ли уведомление регулятора (для подтверждённых утечек по общему регулированию защиты данных — обязательно в течение 72 часов).

Связь с другими каноничными сущностями​

Три каноничных уровня изоляции​

Уровень 1. Логическая изоляция (logical)​

Описание: все тенанты делят общую инфраструктуру (БД, compute, кэш). Изоляция реализована только через программные механизмы — row-level security в БД, проверка tenant_id в каждом запросе, scoped credentials для программного интерфейса.

Применение: баseline для всех тенантов на тарифах Free, Starter, Professional. Это обязательный минимум, никакого «без изоляции» не существует.

Шесть измерений:

ИзмерениеКлассМеханизм
Данныеshared_with_rlsPostgreSQL row-level security policies на каждой таблице
Вычисленияshared_poolОбщий pool сервисов с tenant-aware маршрутизацией
Сетьshared_namespaceОбщий namespace Kubernetes, изоляция через service mesh policies
Хранилищеshared_bucket_with_prefixОбщий Object Storage bucket с префиксами tenant/<tenant_id>/...
Идентичностьshared_realmОбщий realm провайдера идентификации с tenant-scoped токенами
Журналtagged_in_shared_logОбщая система журналирования с тегом tenant_id

Стоимость: низкая (общие ресурсы делятся). Большинство компонентов фиксированные расходы платформы.

Ограничения:

  • Невозможна локализация данных по юрисдикциям (всё в одном регионе).
  • Невозможна гарантированная мощность (capacity envelope).
  • При компрометации общего слоя — затронуты все тенанты.

Уровень 2. Выделенный compute (dedicated_compute)​

Описание: общая инфраструктура хранения, но выделенные вычислительные ресурсы для тенанта. Это даёт гарантированную мощность и операционную изоляцию (нагрузка одного тенанта не влияет на другого).

Применение: тенанты Enterprise tier базовой подписки, премиум-агентства.

Шесть измерений:

ИзмерениеКлассМеханизм
Данныеdedicated_schema_in_shared_dbВыделенная PostgreSQL schema (или dedicated database connection pool)
Вычисленияdedicated_node_in_shared_clusterВыделенные ноды Kubernetes с taints/tolerations для тенанта
Сетьdedicated_namespaceВыделенный Kubernetes namespace с собственным network policy
Хранилищеdedicated_bucketВыделенный Object Storage bucket
Идентичностьdedicated_realm (опционально)Может быть выделенный realm для крупных корпоративных
Журналdedicated_log_streamВыделенный поток в системе журналирования

Стоимость: средняя (стоимость выделенных вычислений + общий бэкенд хранения). Окупается тарифом Enterprise.

Ограничения:

  • Локализация данных частично возможна (бакет можно разместить в нужном регионе), но БД остаётся в общем регионе.
  • При компрометации общей БД — данные могут быть затронуты (хотя ниже риск из-за схемной изоляции).

Уровень 3. Выделенная инфраструктура (dedicated_infrastructure)​

Описание: полностью выделенная инфраструктура для тенанта — собственная БД, собственный кластер, собственный регион (опционально). Это максимальный уровень изоляции, доступный только для крупнейших корпоративных партнёров и для регуляторно-требовательных юрисдикций.

Применение: Enterprise tier по индивидуальному соглашению; тенанты с обязательной локализацией данных по местному законодательству.

Шесть измерений:

ИзмерениеКлассМеханизм
Данныеdedicated_database_in_dedicated_regionВыделенная PostgreSQL instance в нужном регионе
Вычисленияdedicated_clusterВыделенный Kubernetes-кластер
Сетьdedicated_vpcВыделенная виртуальная частная сеть
Хранилищеdedicated_bucket_in_regionВыделенный bucket в нужном регионе
Идентичностьfederated_with_partner_idp (опционально)Федеративная аутентификация с провайдером идентификации тенанта
Журналdedicated_log_destinationЖурналы могут отправляться в собственную систему тенанта

Стоимость: высокая (отдельная инфраструктура). Включена в индивидуальный контракт Enterprise.

Ограничения:

  • Сложность операций — каждый dedicated tenant требует операционного внимания при инцидентах, миграциях, релизах.
  • Замедление релизов — обновления должны прокатываться по нескольким независимым кластерам.

Сводная таблица соответствий​

ТарифБазовый уровеньВозможные апгрейды
Freelogical(нет, только для песочницы)
Starterlogical(нет в стандартном тарифе)
Professionallogical (baseline)dedicated_compute (по запросу с upcharge, не в стандартной конфигурации)
Enterprisededicated_computededicated_infrastructure (по контракту)
Особые юрисдикционные требованияdedicated_infrastructure(без альтернатив)

Шесть измерений изоляции​

Каждый уровень изоляции применяется в шести измерениях одновременно. Это даёт многослойную защиту.

Измерение 1. Изоляция данных​

Что защищается: содержимое таблиц БД от чтения/записи тенанта другого тенанта.

Механизмы:

  • Row-Level Security (RLS) в PostgreSQL — обязательно для всех таблиц с пользовательскими данными. Каждая таблица имеет tenant_id колонку и RLS-policy current_setting('app.tenant_id') = tenant_id.
  • Set tenant context — при каждом запросе к БД устанавливается SET app.tenant_id = '<tenant>' в pre-statement hook ORM.
  • Запрет на bypass RLS — никто, кроме superuser (только для миграций), не может обойти RLS.

Измерение 2. Изоляция вычислений​

Что защищается: ресурсы CPU и RAM от перегрузки одним тенантом.

Механизмы:

  • Tenant-aware rate limiting на каждом сервисе.
  • Resource quotas в Kubernetes для namespace тенанта (для dedicated_compute и выше).
  • Workload-aware маршрутизация — определённые типы запросов направляются в специализированные пулы.

Измерение 3. Изоляция сети​

Что защищается: сетевая видимость между сервисами, чтобы тенант не мог достучаться до сервисов другого тенанта.

Механизмы:

  • Service mesh с mTLS между всеми сервисами.
  • Network policies в Kubernetes ограничивают трафик между namespace.
  • Egress filtering для dedicated тенантов — контроль внешних сетевых соединений.

Измерение 4. Изоляция хранилища​

Что защищается: медиа, документы, артефакты в Object Storage от чтения/записи тенанта другого тенанта.

Механизмы:

  • Bucket policies с проверкой tenant_id префикса.
  • Pre-signed URLs — короткоживущие подписанные ссылки, привязанные к конкретному тенанту.
  • Шифрование данных в покое с tenant-specific ключами (для dedicated_compute и выше).

Измерение 5. Изоляция идентичности​

Что защищается: учётные данные пользователей и API-ключи от использования между тенантами.

Механизмы:

  • Tenant-scoped tokens — каждый JWT-токен содержит tenant_id claim, проверяемый на каждом запросе.
  • API keys с областями (scopes) — ключ привязан к конкретному тенанту.
  • Запрет на федерацию учётных записей между тенантами (один пользователь не может работать в двух тенантах одной учётной записью; для разных тенантов — разные).

Измерение 6. Изоляция журналов​

Что защищается: содержимое журналов от смешивания между тенантами.

Механизмы:

  • Tenant ID tagging во всех структурированных журналах.
  • PII redaction — автоматическая обфускация персональных данных перед записью в общий журнал.
  • Tenant-aware filtering в системе журналирования — оператор видит журналы только своего scope.

Контролируемая межтенантная видимость для команды платформы​

Принцип​

Команда платформы (поддержка, инжиниринг, безопасность) в некоторых случаях должна видеть данные тенанта (для расследования инцидентов, ответа на запросы поддержки). Это разрешено, но строго контролируется через каноничный механизм.

Каноничные роли​

  • platform_support_l1 — может видеть метаданные тенанта (имя, тариф, состояние), без доступа к содержимому данных.
  • platform_support_l2 — может видеть содержимое нечувствительных данных (бронирования, поисковая история) при наличии запроса от тенанта.
  • platform_support_l3 — расширенный доступ при подтверждённом инциденте.
  • platform_security_investigator — расширенный доступ при подозрении на инцидент безопасности.
  • platform_compliance_auditor — доступ для регулярных compliance-проверок.

Поток предоставления доступа​

Запрос на доступ инициируется внутренним пользователем платформы
    ↓
Указание цели (access_purpose) и обоснования (access_justification)
    ↓
Применение правил утверждения по роли:
   - L1 → автоматическое одобрение для метаданных
   - L2 → подтверждение менеджером, обязательная связь с тикетом
   - L3 → подтверждение менеджером + руководителем команды
   - Security investigator → CISO одобрение
   - Compliance auditor → запланированный access по графику
    ↓
Создание CrossTenantAccess со сроком истечения
    ↓
Уведомление тенанта (для L2 и выше) о факте доступа
    ↓
Все действия внутри доступа журналируются в audit_journal
    ↓
По истечении expires_at — доступ автоматически отзывается

Уведомление тенанту​

Для большинства классов доступа (L2 и выше) — обязательное уведомление тенанту в момент предоставления и/или после завершения. Это:

  • Защищает доверие.
  • Соответствует обязательствам по общему регулированию защиты данных (тенант — data controller, имеет право знать о доступе к его данным).
  • Создаёт self-correcting сигнал — тенант видит, что что-то происходит, и может задать вопросы.

Исключения для уведомления:

  • legal_request — некоторые регуляторные запросы запрещают уведомление (для расследований).
  • security_investigation — при активном расследовании компрометации, уведомление может скомпрометировать расследование. После завершения — обязательное уведомление.

Запрет на «вечный доступ»​

  • ❌ Постоянные привилегии «может видеть всё» для отдельных пользователей.
  • ❌ Скрытый доступ через прямое подключение к БД минуя audit log.
  • ❌ Расшаривание учётных данных между членами команды.

Все доступы — временные и журналируемые.

Локализация данных​

Главный принцип​

Некоторые юрисдикции (Россия, Казахстан, Китай, отдельные страны Латинской Америки) требуют физического хранения персональных данных граждан страны внутри страны. Это требование data residency.

Платформа поддерживает локализацию через:

  • TenantIsolationProfile.effective_data_residency_region — назначенный регион для тенанта.
  • Уровень изоляции dedicated_infrastructure в нужном регионе — единственный способ обеспечить полную локализацию.

Каноничные регионы​

  • eu_west — Западная Европа (Франция, Германия) — главный для тенантов EU.
  • eu_central — Центральная Европа (Польша, Чехия) — для специфичных тенантов с локализацией в этом регионе.
  • ua_local — Украина (через локального провайдера или локальный регион в OVHcloud при доступности).
  • kz_local — Казахстан (через локального провайдера).
  • gb_local — Великобритания (после Brexit отдельная юрисдикция).
  • multi_region — данные могут реплицироваться между регионами (для тенантов без жёстких требований).

Compliance-обязательства​

Каждое назначение региона — зафиксированное обязательство в контракте с тенантом:

  • Данные физически хранятся только в указанном регионе.
  • Резервные копии — также в этом регионе (или в специально согласованных регионах).
  • Доступ команды платформы — через аккаунты с привязкой к этому региону.
  • При расширении в новый регион — соответствующая локализация.

Запрет на скрытую репликацию​

  • ❌ Репликация данных тенанта с локализацией в регионы вне согласованного перечня.
  • ❌ Бэкапы в общее (multi_region) хранилище для тенантов с локализацией.
  • ❌ Использование CDN с глобальной репликацией для медиа тенантов с локализацией (медиа должно идти через CDN с региональным присутствием).

Защита от межтенантных утечек​

Многослойная защита​

Каждый запрос проходит проверку tenant_id на нескольких слоях:

  1. API Gateway — извлекает tenant_id из JWT-токена.
  2. Сервис — устанавливает tenant_id в контекст запроса (в request-scoped variable).
  3. ORM — добавляет tenant_id в WHERE для каждого запроса.
  4. PostgreSQL — RLS-policy валидирует tenant_id.
  5. Журналирование — tenant_id тег для каждой записи.

Утечка одного слоя не приводит к компрометации, потому что следующие слои продолжают защиту.

Каноничные проверки​

  • cross_tenant_query_attempt — попытка запроса данных другого тенанта (типично — баг в коде сервиса). Блокируется на уровне БД через RLS, журналируется как IsolationBoundaryCheck с severity high.

  • cross_tenant_cache_leak — обнаружение данных тенанта в кеше другого. Кеш помечен tenant-aware ключом (tenant:<id>:cache_key); на чтении проверяется соответствие.

  • cross_tenant_log_leak — данные одного тенанта в журналах другого. Автоматическая проверка через периодический сканер с PII detection.

  • dedicated_resource_violation — тенант с уровнем dedicated оказался на общем resource. Автоматическая проверка через метаданные resource assignment.

  • data_residency_violation — данные тенанта оказались вне разрешённого региона. Проверка через геокоординаты infrastructure ресурсов и tenant residency requirement.

Автоматический ответ на нарушение​

  • Severity critical — мгновенная блокировка операции, эскалация команде безопасности (на сon-call), создание IsolationIncident, начало процедуры регуляторного уведомления.
  • Severity high — блокировка, журналирование, тикет в очередь команды безопасности на 24 часа.
  • Severity medium — журналирование, тикет в очередь на 72 часа.
  • Severity low — журналирование для последующего ревью.

Реакция на инциденты изоляции​

Классификация инцидентов​

  • data_leak_confirmed — подтверждённая утечка (данные тенанта стали известны другому тенанту или внешнему лицу).
  • data_leak_suspected — подозрение на утечку, расследуется.
  • unauthorized_access — несанкционированный доступ к данным (внутренний или внешний).
  • dedicated_resource_violation — нарушение dedicated boundary без подтверждённой утечки.
  • data_residency_violation — нарушение требования локализации без подтверждённой утечки.

Каноничный поток реакции​

Detection (через автоматическую проверку, ручное расследование, отчёт партнёра)
    ↓
Создание IsolationIncident
    ↓
Containment (изоляция масштаба, блокировка дальнейших операций)
    ↓
   ├── Severity critical: command center активирован, CISO вовлечён
   ├── Severity high: команда безопасности расследует
   └── Severity medium/low: стандартный ticket flow
    ↓
Investigation (RCA — root cause analysis):
   - какие тенанты затронуты
   - какие данные затронуты
   - время начала и продолжительность
   - источник утечки
    ↓
Remediation (исправление root cause, защита от повторения)
    ↓
Notification (уведомление затронутых тенантов и регулятора при необходимости)
    ↓
Resolution (закрытие инцидента, post-mortem, lessons learned)

Регуляторное уведомление​

Для подтверждённых утечек данных по общему регулированию защиты данных (data_leak_confirmed):

  • Уведомление регулятора — в течение 72 часов с момента обнаружения, если утечка может представлять риск для прав и свобод субъектов.
  • Уведомление субъектов данных — без необоснованной задержки, если высокий риск.
  • Журнал — каждый шаг процедуры журналируется для последующего ревью регулятора.

См. Соответствие требованиям регуляторов для полной процедуры.

Post-mortem​

Каждый инцидент с severity high или выше — обязательный post-mortem (анализ после события):

  • Без обвинения (blameless) — фокус на системных причинах.
  • Публичное в команде — все могут изучить и предложить улучшения.
  • С action items — конкретные задачи на улучшение (расширение автоматических проверок, обновление процедур, дополнительное обучение команды).

Триггеры перехода между уровнями​

От logical к dedicated_compute​

  • Подписание контракта Enterprise tier.
  • Запрос тенанта с обоснованием (compliance, гарантированная мощность, изоляция от соседей).
  • Достижение тенантом порога нагрузки, при котором gemeinsame инфраструктура не справляется без влияния на других.

От dedicated_compute к dedicated_infrastructure​

  • Регуляторное требование локализации данных (kz_local, ua_local).
  • Корпоративный контракт с явным требованием dedicated infrastructure.
  • Регуляторно-чувствительная отрасль (государственный сектор, оборона).
  • Финансовая регуляторная нагрузка на тенанта (например, банк), требующая полной изоляции.

Обратные переходы (downgrade)​

  • Изменение тарифа тенанта вниз.
  • Существенное снижение нагрузки.

Обратные переходы — сложные, требуют планирования (миграция данных в общую инфраструктуру при сохранении изоляции). Не происходят автоматически.

Связь с тарифами​

Подробно — в Программный интерфейс как продукт и Архитектурный якорь и бизнес-модель. Здесь — каноничная связь:

ТарифDefault IsolationLevelCompliance возможности
Freelogicalбазовые
Starterlogicalбазовые
Professionallogicalбазовые + опциональный dedicated_compute с upcharge
Enterprisededicated_computeполный набор + опциональный dedicated_infrastructure
Custom Enterprisededicated_infrastructureиндивидуальные SLA, локализация, federated identity

Метрики и наблюдаемость​

Каноничные метрики тенантной изоляции​

  • Распределение тенантов по уровням изоляции — сколько тенантов на каждом уровне.
  • Доля тенантов на dedicated — индикатор зрелости платформы.
  • Среднее время разрешения IsolationBoundaryCheck — операционная метрика.
  • Доля автоматически разрешённых нарушений vs ручных — индикатор зрелости автоматики.
  • Число инцидентов изоляции по severity — операционная метрика.
  • Распределение CrossTenantAccess по access_purpose — для compliance review.
  • Среднее время одобрения CrossTenantAccess — для оптимизации процессов поддержки.

Алерты​

Через Аналитика и бизнес-аналитика и Наблюдаемость и реагирование на инциденты:

  • Алерт при любом IsolationBoundaryCheck severity critical.
  • Алерт при превышении нормального уровня severity high (более 5 за час).
  • Алерт при попытке доступа к dedicated tenant без правильной роли.
  • Алерт при превышении срока CrossTenantAccess без revoke.
  • Алерт при data_residency_violation любого уровня.

События тенантной изоляции​

СобытиеКогдаГлавные потребители
tenant.isolation_level.assignedНазначение уровня тенантуКонтур аудита
tenant.isolation_level.upgradedПовышение уровня (logical → dedicated_compute → dedicated_infrastructure)Команда поддержки, операционная команда
tenant.isolation_level.downgradedПонижение уровняСрочный алерт, обязательное согласование
tenant.data_residency.assignedНазначение региона данныхКонтур compliance
isolation.boundary_check.violation_detectedОбнаружение нарушенияПлатформа данных, оперативная команда (по severity)
isolation.boundary_check.violation_resolvedРазрешение нарушенияКонтур аудита
cross_tenant_access.requestedЗапрос на межтенантный доступApproval workflow
cross_tenant_access.grantedДоступ предоставленТенант (если требуется уведомление), контур аудита
cross_tenant_access.expiredАвтоматическое истечениеКонтур аудита
cross_tenant_access.revoked_earlyДосрочное аннулированиеКонтур аудита
isolation.incident.detectedРегистрация инцидентаКоманда безопасности, оперативная команда
isolation.incident.containedОграничение масштабаКоманда безопасности
isolation.incident.resolvedЗакрытие инцидентаКонтур compliance, post-mortem процесс
isolation.regulatory_notification.completedУведомление регулятораКонтур compliance, leadership

Полная таксономия — в Первоначальная таксономия событий.

Фазы развёртывания​

Фаза Bootstrap (0–6 месяцев)​

Что разворачивается:

  • Каноничная модель (IsolationLevel, TenantIsolationProfile, IsolationBoundaryCheck, CrossTenantAccess, IsolationIncident) зафиксирована.
  • Базовый уровень logical для всех тенантов с RLS на критических таблицах.
  • Базовая система CrossTenantAccess для команды поддержки.
  • Простой набор IsolationBoundaryCheck для самых критических случаев.
  • Закрытие Долга 6 через введение явной Tenant сущности.

Триггер выхода:

  • Запуск партнёрского доступа с тарифом Professional — нужны улучшенные проверки.
  • Появление первого корпоративного партнёра — нужен путь к dedicated_compute.

Фаза 2 — Production isolation (6–18 месяцев)​

Что разворачивается:

  • Полный набор IsolationBoundaryCheck всех классов.
  • Многослойная защита (RLS + сервис + кеш + журнал).
  • Полная процедура CrossTenantAccess с уведомлениями тенантам.
  • Каноничная процедура реакции на инциденты.
  • Audit-журнал с retention 10 лет.
  • Автоматические compliance-проверки.

Триггер выхода:

  • Появление первого корпоративного клиента с требованием dedicated_compute.
  • Появление тенантов из юрисдикций с обязательной локализацией.

Фаза 3 — Dedicated compute available (18–30 месяцев)​

Что разворачивается:

  • Уровень dedicated_compute доступен для Enterprise.
  • Выделенные namespaces, schemas, buckets для назначенных тенантов.
  • Расширенная система мониторинга для dedicated тенантов.
  • Поддержка federated identity для крупных корпоративных партнёров.
  • ML-модели обнаружения аномалий в межтенантных запросах.

Фаза 4 — Dedicated infrastructure (30+ месяцев)​

Что разворачивается:

  • Уровень dedicated_infrastructure доступен для Custom Enterprise.
  • Multi-region инфраструктура с локализацией данных по юрисдикциям.
  • Поддержка специализированных регулятивных режимов (например, для банковского сектора).
  • Индивидуальные операционные процедуры для крупнейших dedicated тенантов.
  • Sovereign cloud (для регулятивно-критичных юрисдикций) — опционально.

Архитектурные решения с тезисным обоснованием​

Решение 1. Три каноничных уровня, не «всё для всех»​

Цель: обеспечить экономически жизнеспособную модель с возможностью поднятия уровня для тех, кому нужно.

Тезисы:

  1. Полная dedicated infrastructure для всех тенантов — экономически нереализуемо.
  2. Только logical для всех — недостаточно для крупных корпоративных и регуляторно-требовательных юрисдикций.
  3. Три уровня покрывают полный спектр потребностей с явной связью с тарифом.
  4. Современные платформы (Salesforce, AWS, Snowflake) — все строят похожую модель уровней. Это база.

Решение 2. Многослойная защита, не один слой​

Цель: обеспечить устойчивость к багам в любом отдельном слое.

Тезисы:

  1. Один слой защиты — единственная точка отказа. Bug в этом слое — компрометация всех тенантов.
  2. Многослойная защита (RLS + сервис + кеш + журнал) — отказ одного слоя не приводит к утечке.
  3. Стандартная практика безопасности (defence in depth).

Решение 3. Контролируемая межтенантная видимость через journaled access​

Цель: разрешить операционно необходимый доступ команды платформы без открытия дыры в безопасности.

Тезисы:

  1. Поддержка должна видеть данные для расследования инцидентов — это операционная необходимость.
  2. Без журнала доступа невозможно ответить регулятору «кто видел эти данные».
  3. Уведомление тенанту — единственный способ сохранить доверие.
  4. Срок истечения — защита от долгосрочных привилегий.

Решение 4. Локализация данных как first-class возможность​

Цель: обеспечить compliance-обязательства для регуляторно-требовательных тенантов.

Тезисы:

  1. Без поддержки локализации платформа недоступна для тенантов в Казахстане, России (если потребуется), и других юрисдикций.
  2. Это не «фича на потом», а архитектурный закон для определённых тенантов.
  3. Совмещение локализации с уровнем dedicated_infrastructure — единственный способ полного соответствия.

Решение 5. Каноничная процедура реакции на инциденты​

Цель: обеспечить корректное и быстрое реагирование при подозрении на утечку.

Тезисы:

  1. Импровизированная реакция в момент инцидента — обычно медленная и неполная.
  2. Каноничная процедура (containment → investigation → remediation → notification) — стандарт индустрии.
  3. Регуляторное уведомление в 72 часа по общему регулированию защиты данных требует процедуры, не импровизации.

Открытые развилки​

Развилка 1. Конкретные пороги для автоматического перехода между уровнями​

При каких объёмах нагрузки тенанта автоматически предлагать переход с logical на dedicated_compute? Конкретные пороги — открытая развилка.

Эскалируется: при появлении первых тенантов, приближающихся к пороговым значениям.

Развилка 2. Поддержка federated identity для всех Enterprise​

Federated identity (SAML, OIDC) — обязательно для всех Enterprise или опционально по запросу? Зависит от рынка.

Эскалируется: при появлении партнёров с требованиями.

Развилка 3. Sovereign cloud для регулятивно-критичных юрисдикций​

В фазе 4 — возможна поддержка sovereign cloud (государственное облако) для тенантов в юрисдикциях с особыми требованиями. Существенная коммерческая возможность с большими операционными сложностями.

Эскалируется: при стратегическом пересмотре в фазе 4.

Развилка 4. ML-модели обнаружения аномалий в межтенантном трафике​

В фазе 3 — ML-модели для обнаружения подозрительного межтенантного трафика. Глубина (от анализа паттернов до автоматических блокировок) — открытая развилка.

Эскалируется: при создании ML-стратегии для безопасности в Платформа машинного обучения.

Развилка 5. Вертикальная специализация уровней изоляции​

Возможны вертикально-специализированные уровни (например, medical_isolation с HIPAA-compliance, financial_isolation с PCI DSS Level 1). Для специфических индустрий — открытая развилка.

Эскалируется: при стратегическом расширении в новые индустриальные сегменты.

Связанная документация​

Корневые архитектурные документы​

Связанные доменные документы​

Документы развития​

Операционная сторона​

Архитектурные правила​