Рекомендуется: Аттестованная облачная инфраструктура SELECTEL

Ниже — целевая спецификация системы для CRM/ERP, маркетплейса путёвок и управления детским лагерем. Она исходит из модели:

• Персональные данные находятся в отдельном защищённом сервисе;
• Лагерь и маркетплейс работают только через API;
• Сервер клиента не имеет пакетного доступа;
• Каждый человек запрашивается отдельно;
• Для получения персональных данных нужны одновременно серверное Разрешение и личный или админский ключ;
• Реальные ПДн не размножаются по бизнес-сервисам;
• Медицинские данные и документы выделены в отдельный контур.

Спецификация техническая и архитектурная. Юридические формулировки, модель угроз и уровень защищённости нужно отдельно подтвердить специалистом по 152-ФЗ и требованиям ФСТЭК. В API обязательно учитывать проверки объектного и полевого доступа: OWASP отдельно выделяет Broken Object Level Authorization и Broken Object Property Level Authorization как критические риски API.

1. Назначение системы

1.1. Назначение

Система обеспечивает:

• Продажу путёвок;
• Работу маркетплейса лагерей;
• Управление заявками;
• Регистрацию родителей и детей;
• Документооборот;
• Работу с медицинскими документами;
• Управление заездами и группами;
• CRM/ERP-функции лагеря;
• Разграниченный доступ пользователей;
• Безопасное предоставление персональных данных по единичному запросу.

1.2. Основные принципы

1. Минимизация данных. Каждый сервис получает только необходимые поля.
2. Изоляция организаций. Один лагерь не может получить данные другого.
3. Объектная авторизация. Проверяется не только роль, но и конкретный человек, заказ или документ.
4. Полевая авторизация. Разные роли видят разные поля одного объекта.
5. Двойное доверие. Для чувствительных данных нужны серверная интеграция и пользовательский криптографический ключ.
6. Отсутствие пакетной выдачи. API не поддерживает массовое чтение персональных данных.
7. Шифрование. Данные, документы и резервные копии шифруются.
8. Ключи отдельно от данных. Ключи находятся в KMS/HSM, а не в БД.
9. Аудит. Каждый доступ фиксируется.
10. Нулевое доверие к клиентским серверам. Взломанный лагерь рассматривается как потенциально враждебный клиент.
11. Быстрый отзыв доступа. Сертификат, ключ или tenant можно отключить независимо от остальных клиентов.
12. Запрет собственных целей. Защищённое юрлицо не использует данные клиентов для своих целей без отдельного основания.

2. Состав системы

Public Marketplace │ ▼ Platform Core │ ├── Identity and Access Service ├── Order and Booking Service ├── Catalog Service ├── Payment Service ├── Notification Service └── Integration Gateway │ ▼ Protected Data Platform │ ┌───────────┼───────────┐ ▼ ▼ ▼ Data API Document API Audit API │ │ │ ▼ ▼ ▼ ПДн БД Private Storage Audit Storage │ ▼ KMS/HSM 

2.1. Public Marketplace

Хранит и показывает:

• лагеря;
• программы;
• описания;
• цены;
• расписание;
• наличие мест;
• правила бронирования;
• обезличенные отзывы;
• публичные изображения;
• технические идентификаторы предложений.

Не хранит:

• медицинские документы;
• паспортные данные;
• полные анкеты детей;
• полные карточки родителей;
• внутренние журналы доступа.

2.2. Platform Core

Хранит:

• tenant_id;
• camp_id;
• order_id;
• child_ref;
• статусы заказа;
• статус оплаты;
• статус документов;
• дату заезда;
• программу;
• группу;
• технические события;
• обезличенные метрики.

Platform Core не имеет прямого доступа к БД ПДн.

2.3. Protected Data Platform

Это отдельный защищённый сервис и отдельный контур безопасности. Он хранит:

• ФИО;
• даты рождения;
• контакты родителей;
• адреса;
• данные законных представителей;
• документы;
• согласия;
• медицинские сведения;
• связи между внутренними идентификаторами и субъектами;
• историю изменений;
• политики хранения.

2.4. Identity and Access Service

Отвечает за:

• пользователей;
• организации;
• роли;
• ключи;
• сертификаты;
• сессии;
• MFA;
• WebAuthn/FIDO2;
• отзыв credentials;
• назначение полномочий;
• выпуск capability на операцию.

2.5. Integration Gateway

Единственная точка входа для внешних серверов лагерей и маркетплейсов.

Отвечает за:

• mTLS;
• проверку сертификата;
• проверку service token;
• rate limiting;
• маршрутизацию;
• tenant binding;
• антиперебор;
• WAF;
• блокировку клиента;
• передачу запроса в Policy Engine.

2.6. Audit Service

Хранит неизменяемые события:

• кто запросил;
• от имени какой организации;
• какой сервер;
• какой пользователь;
• какой объект;
• какое поле;
• какая операция;
• причина;
• результат;
• время;
• сертификат;
• request ID;
• решение политики.

3. Юридическая модель

3.1. Лагерь

Лагерь является оператором данных, которые используются для:

• оформления путёвки;
• исполнения договора;
• размещения ребёнка;
• связи с родителями;
• организации заезда;
• медицинского и лагерного учёта;
• выполнения обязательных процедур.

3.2. Платформа

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

• аккаунт маркетплейса;
• заказ;
• платёж;
• поддержка;
• антифрод;
• технический аудит;
• собственные уведомления;
• собственный маркетинг при наличии отдельного основания.

В части данных лагеря платформа работает по поручению, если не определяет собственные цели обработки.

3.3. Protected Data Service

Защищённое юрлицо действует как обработчик:

• хранит данные;
• выполняет операции по API;
• выдаёт разрешённые поля;
• хранит документы;
• ведёт аудит;
• выполняет резервное копирование;
• удаляет или возвращает данные.

Запрещается:

• использовать данные для собственной рекламы;
• обучать модели на данных клиента;
• объединять данные разных лагерей;
• продавать профили;
• самостоятельно менять цели обработки;
• передавать данные партнёрам по собственной инициативе.

3.4. Обязательные документы

Нужны:

1. договор лагеря с платформой;
2. поручение обработки ПДн;
3. договор платформы с Protected Data Service;
4. договоры с хостингом и субподрядчиками;
5. регламент межсервисного доступа;
6. политика хранения;
7. модель угроз;
8. регламент реагирования на инциденты;
9. регламент удаления и возврата данных;
10. политика управления ключами;
11. политика управления доступом;
12. политика обработки запросов субъектов.

4. Модель данных

4.1. Основные идентификаторы

Используются непрозрачные случайные идентификаторы:

tenant_id camp_id person_id child_id guardian_id order_id document_id consent_id employee_id request_id 

Идентификаторы:

• не являются последовательными;
• не содержат ФИО;
• не содержат дату рождения;
• не включают телефон;
• не раскрывают принадлежность к лагерю;
• генерируются криптографически безопасным генератором.

4.2. Бизнес-сущности

Tenant

tenant_id legal_name operator_type status retention_policy_id key_policy_id created_at blocked_at 

Camp

camp_id tenant_id name address programs contacts status 

Person

person_id tenant_id person_type display_name_encrypted birth_date_encrypted status created_at updated_at deleted_at 

Guardian

guardian_id person_id relationship contact_data_encrypted legal_representative_status verification_status 

Child

child_id person_id birth_date_encrypted guardian_links camp_links status 

Order

В Platform Core:

order_id tenant_id camp_id child_ref customer_ref program_id payment_status booking_status document_status arrival_date 

В Protected Data Platform:

order_id child_id guardian_id operator_id 

Medical Profile

Отдельная сущность:

medical_profile_id child_id tenant_id clearance_status critical_alert_encrypted restrictions_encrypted valid_from valid_to 

Document

document_id tenant_id subject_id document_type storage_object_id classification checksum uploaded_at expires_at deleted_at 

Consent

consent_id subject_id operator_id purpose data_categories document_version accepted_at source revoked_at evidence_reference 

5. Классификация данных

5.1. Public

• описание лагеря;
• программа;
• цена;
• наличие мест;
• публичные правила;
• общие контакты организации.

5.2. Internal

• tenant_id;
• order_id;
• статусы;
• расписание;
• обезличенные отчёты;
• технические события.

5.3. Personal

• ФИО;
• телефон;
• email;
• адрес;
• дата рождения;
• данные законного представителя.

5.4. Restricted

• паспортные документы;
• медицинские документы;
• аллергии;
• ограничения;
• специальные категории данных;
• внутренние медицинские комментарии;
• документы законного представителя.

Для каждой категории создаётся отдельная политика доступа. Один endpoint не должен возвращать объект со всеми категориями сразу.

6. Архитектура доверия

6.1. Два обязательных доказательства

Для чувствительных данных нужны:

1. доказательство сервера интеграции; 2. доказательство пользователя или администратора. 

Сервер лагеря доказывает:

я — интеграция camp-crm-17 

Пользователь доказывает:

я — employee-456 

Protected Data Service самостоятельно проверяет:

может ли employee-456 через camp-crm-17 в tenant camp-17 получить поле phone объекта person-8f2c для конкретной операции 

6.2. Ключ сервера

Для каждого сервера и интеграции:

service_id tenant_id certificate public_key scopes status issued_at expires_at revoked_at 

Нельзя использовать:

• общий ключ всех лагерей;
• общий сертификат всей платформы;
• бессрочный API key;
• ключ в исходном коде;
• ключ в открытом .env.

6.3. Ключ пользователя

Для каждого сотрудника:

employee_id tenant_id role public_key authenticator_type status last_used_at revoked_at 

Рекомендуемый механизм:

• WebAuthn/FIDO2;
• аппаратный ключ;
• passkey на управляемом устройстве;
• отдельный ключ для администратора;
• отдельный ключ для медицинского сотрудника.

Приватный ключ не передаётся серверу.

6.4. Административные ключи

Разделить:

organization-admin medical-admin security-admin platform-admin infrastructure-admin 

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

• аппаратный ключ;
• MFA;
• временное повышение привилегий;
• bastion host;
• запись административной сессии;
• обязательную причину;
• двойное подтверждение;
• уведомление владельца организации.

7. Авторизация

7.1. Политика deny by default

Если операция не описана в политике — она запрещена.

Нельзя иметь универсальные scopes:

read:any write:any admin:any 

Нужны узкие права:

read:booking_status read:contact_for_order read:safety_alert read:medical_document write:document_status manage:employees 

7.2. Проверки каждого запроса

Каждый запрос проверяет:

service_id certificate tenant_id actor_id actor_role resource_id resource_tenant operation fields purpose nonce expires_at rate_limit risk_score 

7.3. Объектная авторизация

Нельзя разрешать доступ только потому, что:

роль = manager tenant = camp-17 

Нужно проверить:

person_id связан с camp-17 person_id связан с конкретным order_id employee имеет доступ к этому order_id операция разрешена его ролью 

7.4. Полевая авторизация

Например:

booking_view: display_name birth_date booking_status manager_contact_view: display_name phone counselor_view: display_name safety_alert medical_view: full_medical_profile medical_documents 

API никогда не принимает произвольный список полей от клиента.

8. API

8.1. Принцип API

API строится вокруг конкретных операций, а не вокруг универсального доступа к таблицам.

Плохо:

GET /persons/{id} GET /persons?tenant_id=camp-17 GET /persons/{id}?fields=* 

Хорошо:

GET /v1/orders/{order_id}/booking-view GET /v1/orders/{order_id}/parent-contact GET /v1/children/{child_id}/safety-view GET /v1/documents/{document_id}/temporary-access POST /v1/orders/{order_id}/document-status 

8.2. Запрос одного человека

GET /v1/persons/{person_id}/contact Authorization: DPoP <access_token> X-Request-ID: req_... X-Operation-Proof: <signed_operation> 

Но предпочтительнее контекстный endpoint:

GET /v1/orders/{order_id}/participant/contact 

Так сервер сам разрешает заказ в конкретную запись ПДн и не позволяет клиенту произвольно перебирать person_id.

8.3. Ответ

{ "request_id": "req_7d...", "person_ref": "p_8f2c", "projection": "contact", "data": { "phone": "+7..." }, "expires_at": "2026-09-25T08:35:00Z" } 

Не возвращать:

• внутренние ключи БД;
• полные связи;
• лишние поля;
• медицинские сведения;
• документы;
• технические секреты.

8.4. Ошибки

Для несуществующего и запрещённого объекта желательно возвращать одинаковый ответ:

404 Not Found 

Не раскрывать:

человек существует, но вам запрещён 

Ошибки не должны содержать:

• SQL;
• пути файлов;
• внутренние ID;
• конфигурацию;
• названия таблиц;
• stack trace.

9. Подтверждение операции

9.1. Operation Proof

Для доступа к чувствительному полю создаётся подписываемая операция:

{ "tenant_id": "camp-17", "actor_id": "employee-456", "resource_id": "person-8f2c", "action": "read_parent_phone", "fields": ["phone"], "purpose": "arrival_coordination", "nonce": "n_...", "expires_at": "2026-09-25T08:35:00Z", "max_uses": 1 } 

Пользовательский ключ подписывает каноническое представление этой структуры.

9.2. Capability

После успешной проверки система выпускает короткое разрешение:

capability_id actor_id tenant_id resource_id action allowed_fields issued_at expires_at max_uses status 

Срок:

• обычный контакт: 30–120 секунд;
• документ: 30–60 секунд;
• медицинские сведения: 30–60 секунд;
• административная операция: до завершения конкретного действия.

9.3. Повторное использование

Каждая capability имеет:

• nonce;
• срок действия;
• счётчик использования;
• привязку к запросу;
• статус отзыва.

Повтор старой подписи должен отклоняться.

10. Криптография

10.1. Канал

• TLS 1.3;
• mTLS для серверных интеграций;
• сертификат каждого клиента отдельно;
• отзыв сертификатов;
• ротация;
• запрет слабых cipher suites;
• проверка имени и цепочки сертификатов.

10.2. Аутентификация

• WebAuthn/FIDO2 для пользователей;
• аппаратный ключ для админов;
• короткие access tokens;
• refresh tokens с ротацией;
• DPoP или mTLS-bound tokens для server-to-server;
• запрет передачи bearer-токенов через URL.

10.3. Шифрование данных

Шифровать:

• поля ПДн на уровне приложения;
• БД;
• документы;
• backup;
• журналы, содержащие ПДн;
• временные файлы;
• экспорт.

Для разных tenant желательно применять разные data encryption keys.

10.4. Управление ключами

KMS/HSM ├── master key ├── tenant key ├── document key ├── backup key └── audit key 

Ключи:

• не хранятся в БД;
• не хранятся в исходном коде;
• не входят в backup вместе с ciphertext;
• имеют ротацию;
• имеют аудит использования;
• могут быть отозваны для одного tenant.

11. Сетевая архитектура

Internet │ ▼ WAF / DDoS Protection │ ▼ API Gateway │ ▼ Integration Zone │ ▼ Policy Engine │ ▼ Protected Data API │ ├── PostgreSQL Private Network ├── Document Storage Private Network ├── KMS/HSM └── Audit Network 

Запретить:

• прямой доступ из интернета к БД;
• прямой доступ лагерь → БД;
• прямой доступ лагерь → object storage;
• доступ клиентов к KMS;
• доступ клиентов к backup;
• общий административный SSH;
• межtenant-соединения.

Доступ администратора:

админское устройство ↓ VPN ↓ bastion ↓ временное разрешение ↓ конкретный сервис 

12. Изоляция tenant

12.1. Логическая изоляция

Каждая запись содержит tenant_id.

Каждый запрос автоматически получает tenant из:

• сертификата;
• service identity;
• пользовательской сессии;
• серверной политики.

Нельзя доверять tenant_id из JSON.

12.2. База данных

Использовать несколько уровней:

1. проверка tenant в приложении;
2. row-level security;
3. ограничения внешних ключей;
4. тесты на tenant breakout;
5. отдельные роли БД;
6. запрет прямого SQL от клиента.

Для крупных клиентов возможны:

• отдельная схема;
• отдельная база;
• отдельное object storage;
• отдельный ключ KMS;
• отдельный экземпляр сервиса.

13. Документы

13.1. Загрузка

1. Авторизация пользователя. 2. Проверка tenant и документа. 3. Проверка размера. 4. Проверка MIME и расширения. 5. Антивирусная проверка. 6. Изоляция в quarantine storage. 7. Обработка файла. 8. Перенос в private storage. 9. Запись события аудита. 

Запрещать:

• исполняемые файлы;
• активные макросы;
• внешние ссылки в документах;
• публичные object URLs;
• произвольные имена файлов;
• постоянные ссылки.

13.2. Чтение

1. Пользователь запрашивает документ. 2. Проверяется роль. 3. Проверяется конкретный document_id. 4. Проверяется tenant. 5. Проверяется purpose. 6. Создаётся одноразовый access token. 7. Ссылка живёт 30–60 секунд. 8. Скачивание фиксируется. 

Для медицинских документов:

• отдельный storage;
• отдельные ключи;
• отдельные роли;
• отдельный аудит;
• отсутствие доступа у менеджера;
• запрет массового скачивания.

14. Пользовательские роли

Роль	Основной доступ
Покупатель	Свои заказы и свои документы
Менеджер	Заявки, статусы, ограниченные контакты
Вожатый	Только назначенные дети и минимальные предупреждения
Медработник	Медицинские сведения назначенных детей
Администратор лагеря	Управление организацией и разрешёнными отчётами
Администратор платформы	Только функции платформы
Администратор безопасности	Ключи, блокировки, аудит без обычного просмотра ПДн
Инфраструктурный администратор	Сервисы и инфраструктура через JIT-доступ

15. Защита при взломе клиента

15.1. Взлом сервера лагеря

Атакующий получает:

• локальную CRM;
• service credentials;
• доступ к API в рамках scopes.

Он не получает:

• БД Protected Data Service;
• KMS;
• backup;
• данные других tenant;
• пользовательские ключи;
• медицинские данные без user proof;
• пакетный endpoint.

Меры:

• отзыв сертификата;
• отзыв токенов;
• блокировка tenant;
• режим только статусов;
• сохранение аудита;
• проверка выданных ответов;
• уведомление по процедуре инцидента.

15.2. Взлом frontend

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

• короткая сессия;
• данные только текущего объекта;
• отсутствие массивов в initial payload;
• отсутствие ПДн в localStorage;
• запрос чувствительного поля только по действию;
• пользовательский ключ;
• capability на одну операцию;
• автоматическое завершение сессии.

15.3. Взлом ключа

Для каждого ключа:

• отдельный статус;
• отдельная ротация;
• отдельный журнал;
• отдельный отзыв;
• минимальные scopes;
• ограничение скорости;
• привязка к tenant;
• аномалия → карантин.

16. Антиэксфильтрация

Пакетный API запрещён архитектурно.

Дополнительные ограничения:

max requests per minute max unique resources per hour max failed IDs max document reads max sensitive reads max concurrent requests 

Обнаруживать:

• перебор ID;
• необычное количество запросов;
• запросы ночью;
• новый fingerprint;
• доступ к запрещённым полям;
• смену сетевого профиля;
• повторяющиеся ошибки;
• попытки разных tenant;
• скачивание документов сериями.

Реакция:

1. ограничить rate; 2. отключить restricted fields; 3. перевести tenant в карантин; 4. отозвать token; 5. отозвать сертификат; 6. сохранить audit; 7. открыть инцидент. 

17. Аудит

17.1. Обязательные события

• вход;
• выдача токена;
• проверка подписи;
• отказ в доступе;
• чтение объекта;
• чтение конкретного поля;
• скачивание документа;
• изменение данных;
• удаление;
• экспорт;
• создание сотрудника;
• изменение роли;
• выпуск ключа;
• отзыв ключа;
• изменение политики;
• административный доступ;
• срабатывание антифрода.

17.2. Формат события

{ "event_id": "evt_...", "request_id": "req_...", "timestamp": "2026-09-25T08:30:00Z", "tenant_id": "camp-17", "service_id": "camp-crm-17", "actor_id": "employee-456", "resource_type": "person", "resource_id": "p_8f2c", "operation": "read", "fields": ["phone"], "purpose": "arrival_coordination", "decision": "allow", "certificate_fingerprint": "...", "risk_score": 12 } 

Журнал:

• append-only;
• недоступен клиентам;
• защищён от изменения;
• реплицируется отдельно;
• содержит минимум ПДн;
• имеет собственную политику хранения.

18. Резервные копии

Бэкапы должны быть:

• зашифрованы;
• отделены от production;
• недоступны обычному приложению;
• защищены от удаления клиентом;
• immutable;
• с отдельными ключами;
• с регулярным тестом восстановления;
• с журналом операций;
• с отдельной учётной записью backup.

Сценарий восстановления:

backup ↓ quarantine environment ↓ проверка целостности ↓ проверка malware ↓ восстановление ↓ ротация credentials ↓ возврат в production 

19. Жизненный цикл данных

19.1. Создание

• определить цель;
• определить оператора;
• определить категорию;
• определить срок;
• получить необходимое основание;
• записать источник;
• создать subject_id.

19.2. Использование

• только по назначенной цели;
• только по нужной роли;
• только в рамках tenant;
• с аудитом;
• с минимальной проекцией.

19.3. Уточнение

• фиксировать автора изменения;
• сохранять версию;
• не менять историю незаметно;
• обновлять связанные системы только через API.

19.4. Удаление

Удалять или обезличивать:

• по окончании цели;
• после истечения срока;
• по основанию оператора;
• при отзыве, если нет законного основания продолжать обработку;
• из production;
• из рабочих индексов;
• из временных файлов;
• из доступных backup по политике жизненного цикла.

20. Публичный и чувствительный интерфейс

Публичный интерфейс

Можно размещать:

• каталог;
• цены;
• описания;
• расписание;
• наличие мест;
• форму заказа.

Чувствительный интерфейс

Отдельный домен или отдельный security boundary:

• авторизация;
• MFA;
• WebAuthn;
• строгий CSP;
• отсутствие сторонней аналитики;
• отсутствие внешних скриптов;
• короткие сессии;
• запрет iframe;
• защита от CSRF;
• защита от XSS;
• запрет кэширования ответов;
• Cache-Control: no-store.

21. Необходимые тесты

Авторизация

• запрос чужого person_id;
• подмена tenant_id;
• подмена actor_id;
• подмена роли;
• изменение fields;
• повтор старой capability;
• использование просроченной подписи;
• чтение медицинских данных менеджером;
• чтение документа без user proof;
• вызов endpoint без server proof.

Изоляция

• лагерь A пытается читать лагерь B;
• пользователь A пытается читать пользователя B;
• клиент меняет camp_id;
• клиент подставляет чужой order_id;
• клиент подставляет чужой document_id.

Антиэксфильтрация

• перебор ID;
• 404 enumeration;
• параллельные запросы;
• превышение rate limit;
• скачивание документов;
• повторная отправка одного запроса;
• использование украденного токена;
• новый сертификат;
• автоматические ночные запросы.

Инфраструктура

• отсутствие доступа к БД из интернета;
• отсутствие доступа клиента к KMS;
• восстановление backup;
• отзыв сертификата;
• ротация ключей;
• отключение tenant;
• отказ одного региона или узла;
• восстановление после ransomware.

22. Реализация MVP

Этап 1

• Platform Core;
• Protected Data Service;
• PostgreSQL в private network;
• API Gateway;
• mTLS;
• отдельный сертификат каждого клиента;
• tenant isolation;
• единичные object-level API;
• журналирование;
• шифрование backup;
• ручной отзыв ключей.

Этап 2

• Identity Service;
• WebAuthn/FIDO2;
• user keys;
• короткие capabilities;
• отдельные роли;
• документное хранилище;
• медицинский контур;
• rate limits;
• автоматический quarantine.

Этап 3

• KMS/HSM;
• envelope encryption;
• DPoP или mTLS-bound tokens;
• SIEM;
• anomaly detection;
• immutable audit;
• JIT-admin;
• автоматическая ротация;
• регулярные penetration tests.

23. Пример полной операции

Сотрудник хочет увидеть телефон родителя.

1. Сотрудник входит через WebAuthn. 2. Identity Service подтверждает employee_id. 3. Frontend отправляет order_id. 4. Protected Data Service находит связанного guardian. 5. Policy Engine проверяет: - tenant; - роль; - заказ; - поле phone; - цель; - срок; - риск. 6. Формируется operation challenge. 7. Сотрудник подтверждает операцию ключом. 8. Выдаётся capability на 60 секунд. 9. Data Service расшифровывает только phone. 10. Возвращается минимальная проекция. 11. Событие записывается в Audit Service. 12. Capability автоматически истекает. 

При взломе сервера лагеря без ключа сотрудника:

service proof есть user proof отсутствует результат: 403 

При взломе frontend с украденной сессией:

сессия есть объект и роль проверяются capability короткая выдаётся только конкретное поле все действия журналируются 

При переборе объектов:

аномалия → rate limit → запрет restricted fields → quarantine tenant → отзыв credentials 

24. Итоговая формула системы

Скомпрометированный лагерь не имеет прямого доступа к БД не имеет доступа к KMS не имеет доступа к backup не имеет пакетного API не имеет пользовательских ключей не имеет медицинских scopes Для получения конкретного ПДн нужны: server identity tenant binding valid user/admin key concrete resource concrete operation allowed field valid purpose unexpired capability successful policy check 

Целевая модель:

Server Key подтверждает интеграцию User/Admin Key подтверждает сотрудника и операцию Policy Engine проверяет tenant, роль, объект и поле Protected Data Service расшифровывает только необходимое Audit Service фиксирует выдачу Risk Engine блокирует аномалию 

Именно такая архитектура даёт нужный эффект: при взломе сервера лагеря атакующий не получает центральную базу и не может произвольно запрашивать данные. Без личного или админского ключа он не получает чувствительные поля, а даже при компрометации пользовательского интерфейса доступ ограничивается конкретной сессией, конкретным объектом, конкретной операцией и коротким временем действия.