Безопасность

При разработке платформы соблюдаются стандарты безопасности OWASP. Получение данных злоумышленником, без получения доступа к хостовой ОС сервера невозможна благодаря шифрованию каналов, дисковых разделов, а также оперативной памяти при осуществлении вычислений над совместными данными (с данными других партнеров).

Сеть

Трафик между подами в пределах одного сервера

Коммуникация между подами в пределах одной ноды осуществляется в пределах виртуальной сети кластера.

Трафик между подами в пределах одного сервера не шифруется.

Трафик между подами, расположенными на разных серверах

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

Шифрование трафика между серверами кластера зависит от настроек кластера. Мы настоятельно рекомендуем включать шифрование при настройке кластера. Например, с помощью использования WireGuard в RKE2

Трафик между партнерами

Партнеры могут коммуницировать между собой двумя способами:

• Путем записи сообщений и изменения информации в блокчейн
• Путем обращения к SGX-анклаву на стороне партнера

Обмен данными между блокчейн-нодами осуществляется с помощью Network Peer Protocol, который криптографически и с помощью механизма консенсуса защищен от вмешательств.

Канал между SGX-серверами защищается с помощью протокола mTLS, доверие, при этом, вместо корневых сертификатов удостоверяющих центров, осуществляется на основе процедуры аттестации Intel SGX. С помощью mTLS шифруется трафик приложений, прозрачно для них самих.

Хранилище

Одним из требований при настройке кластера является использование StorageClass с поддержкой шифрования разделов для виртуальных машин DataLab. Рекомендуемая Vaultee реализация Longhorn поддерживает шифрование с помощью dm_crypt

Реквизиты доступа к БД и другим внешним сервисам

Все реквизиты доступа к базам данных и другим внешним сервисам хранятся Secrets кластера. В Rancher Kubernetes Engine 2, секреты шифруются по умолчанию с помощью AES256 ключа, который хранится локально (AESCBC провайдер). Возможно также использование KMS. В клиентской части не хранятся токены, содержащие конфиденциальную информацию.

Используемые токены

Токен Front-end App → CDP

Токен используется для аутентификации пользовательского приложения (UI), работающего браузера в API CDP модуля. Хранится в браузере пользователя в cookie.

Тип: многоразовый

Формат кодирования: JWT

Алгоритм подписи: HS256

Ключ: случайно сгенерированный секрет, хранящийся в файлах конфигурации CDP-модуля.

Пример payload:

{
  "id": "5fbee963dc5fff53a86e0f7e",
  "type": "user",
  "iat": 1629380581,
  "exp": 1632980581
}

Токен TEE Module → TEE Module

Токен используется для аутентификации TEE-модулей между компаниями (например, при процессе сборки датасетов). Токен содержит хеш от тела HTTP-запроса (sha256), генерируется каждый раз заново на каждое обращение к серверу.

Тип: одноразовый

Формат кодирования: JWT

Алгоритм подписи: RS256

Ключ: случайно сгенерированная на этапе инсталляции пара ключей. Секретный ключ хранится в конфигурационных файлах CDP-модуля. Публичный ключ хранится в блокчейн.

Пример payload:

{
  "id": "org_blockchain_account_id",
  "type": "account",
    "hash": "da84e5104ec02982515127adda821ffc533acf7f07bd9b5839f31239e888feea",
  "iat": 1629380581,
  "exp": 1632980581
}

Токен на получение данных

Токен используется для аутентификации запроса на получение данных в датасервисе. Во время процесса согласования датасета в контуре каждой компании, на сервере согласующей компании формируется токен (случайно сгенерированная последовательность байт длиной 32 байт), записывается локально в собственную БД датасервиса и передается на сервер, откуда был инициирован запрос на данные. Подробнее данный процесс описан тут

Тип: одноразовый

Формат кодирования: JWT

Алгоритм подписи: HS256

Ключ: случайно сгенерированный секрет, хранящийся в файлах конфигурации DataService-модуля.

Вычисления в анклавах

Шифрование памяти

Любая работа с данными партнеров осуществляется только в анклавах Intel SGX. При работе в анклаве память приложения полностью шифруется и недоступна администратору сервера, операционной системе или привилегированным процессам.

Аттестация

Помимо шифрования памяти процесса, при передаче данных партнеру, важно убедиться что на его стороне работает подлинное приложение в подлинном анклаве. Это достигается с помощью части технологии SGX под названием Аттестация.

Упрощенно, процесс аттестации состоит из следующих шагов:

1. Анклав, которому нужно доказать свою подлинность другой стороне, генерирует т.н. квоту, содержащую информацию о процессоре и хеше процесса, запущенного в анклаве, подписанную секретным ключом анклава

Структура квоты:

QE Report квоты может содержать несколько десятков байт свободной полезной нагрузки. Эти байты используются для того, чтобы передать какие-то данные принимающей стороне. В частности, это данные для генерации общего секрета при реализации протокола mTLS.

2. Сгенерированную квоту анклав отправляет принимающей стороне
3. Принимающая сторона верифицирует квоту, отправляя её на сервер Intel, либо используя локальный кеширующий сервер

4. После проверки, принимающая сторона также генерирует свою квоту и отправляет другой стороне, а так в свою очередь её верифицирует. Таким образом устанавливается взаимное доверие между анклавами, а благодаря возможности передать свободную информацию вместе с квотой, передаются необходимые данные для протокола mTLS и генерируется общий секрет, с помощью которого осуществляется защита трафика между анклавами.

Персональные данные

• Исходные данные хранятся на инфраструктуре в контуре каждой из компаний, и не покидают периметры компаний.
• Пересечение данных выполняется в конфиденциальной среде, без возможности стороннего доступа, Пересечение данных выполняется в конфиденциальной среде, без возможности стороннего доступа, а также без возможности выгрузки данных из DataLab. При работе в изолированной среде DataLab данные преобразуются в хешированный формат. Среда DataLab носит только временный характер, не предоставляя постоянное хранение данных.
• Выгрузка только ID напрямую в рекламные кабинеты (если применимо)
• Обмен данными возможен только в отношении данных, для которых отмечено наличие согласие, получено разрешение владельца на доступ к данным и сформировано смарт-поручение на обработку данных. Обмен данными возможен только между участниками, которые вошли в соглашение, регулирующее условия обработки данных, обязанности и ответственность, а также статусы сторон при обработке данных. Кроме этого, все кейсы обмена данными, состав и формат данных, условия преобразования, чувствительность фичей и параметры матчинга проходят предварительное согласование и валидацию участниками обмена.
• Все пользователи, которые работают с данными на платформе, проходят ознакомление с условиями и ограничениями в области обработки персональных данных. Клиенты платформы обязаны проводить обучение своих пользователей в части условий и ограничений в области обработки персональных данных.
• Дополнительно контролируются согласия пользователей на передачу данных партнерам и коммуникации
• Конечными результатами работы математических моделей могут являться только агрегированные данные в привязке к хешированному идентификатору пересеченной записи. Платформа не предусматривает обмен непреобразованными данными.

Процесс взаимодействия между TEE и CAS

CAS

Для того, чтобы TEE в разных компаниях могли доверять друг другу а также сохранять доверие при обновлении версий Enclave Server и скриптов, существует специальный сервис CAS (Configuration and Attestation Service). CAS работает в анклаве SGX, его уникальный хеш (MRENCLAVE) известен всем взаимодействующим с ним анклавам. Таким образом, все анклавы доверяют этому сервису по умолчанию, посредством процедуры аттестации Intel SGX. CAS хранит, так называемые, сессии, которые содержат общие секреты. Общие секреты, в свою очередь, используются анклавами для проверки подлинности друг друга и установки защищенных соединений. Получить доступ к общим секретам могут только анклавы, принадлежащие сессии.

Генерация секретов

Общий секрет - это случайная последовательность байт, сгенерированная с помощью генератора псевдослучайных чисел SGX в TEE и хранящаяся в в его памяти. Пользователь, в том числе и привилегированный не имеет доступ к секрету.

Постоянное хранилище

Сгенерированные ключи также сохраняются на диск для восстановления в памяти после перезапуска. В качестве постоянного хранилища используется база данных SQLite. Данные, сохраняемые на диск шифруются с помощью ключа, сформированного с помощью механизма KDF, где в качестве секретного значения используется случайный ключ, сохраненный на диске в открытом виде, а в качестве парольной фразы SGX Sealing Key (EGETKEY). SGX Sealing Key - это уникальный ключ, получаемый с помощью инструкции EGETKEY, которую можно вызвать только из анклава. Ключ уникален для связки Процессор+Хеш анклава (MRENCLAVE).

Каналы

CAS обращается к серверам Intel для получения PCK Cert для генерации и валидации квот.

К CAS обращается сервис ESP для создания “сессии”. ESP получает обратно идентификатор сессии, который затем передает анклавам для запуска.

ESP

Сервис ESP используется для подписи новых версий Enclave Service а также для начального конфигурирования анклавов при запуске.

Сервис ESP хранит секретный ключ сессии с помощью которого подписывает кей-теги. Кей-теги - это специальные структуры, содержащие уникальный слепок внутренней файловой системы анклава. Когда CI/CD собирает новую версию Enclave Service, он отправляет полученные при сборке кей-теги, получая в ответ их подпись. Анклав с кей-тегами, подписанными валидным ключом сессии могут получить доступ к общим секретам сессии в CAS и осуществлять взаимодействие между анклавами.

ESP предоставляет API для анклавов, которые, в свою очередь, обращаясь к нему с помощью известного API KEY (уникального для каждой компании) получают данные начальной конфигурации:

• IP-адрес CAS
• ID сессии для запроса в CAS

Конфигурация подключения к CAS и другим анклавам

• Приватный ключ для шифрования сообщений между CAS и анклавом
• Название сессии, хеш сессии
• Способ аттестации: prod/dev

Передаваемые данные в рамках взаимодействия ESP и CAS

Процесс инициации и аттестации TEE

1. TEE → ESP

   TEE инициирует сессию с ESP в запросе, передает:

• API-key - ключ приложения
• env - параметры подключения анклава (ip-адрес, порты)

2. ESP → TEE

   ESP верифицирует данные и возвращает в ответ:

   • Адрес для подключения к CAS
   • id сессии
   • Название сессии

   Их TEE использует для подключения к CAS.

3. TEE

   Стартует с указанным названием сессии.

4. TEE → CAS

   Получает квоту от CAS.

5. TEE → LAS

   LAS - проверка подлинности CAS, путем валидации полученной квоты.

6. TEE → CAS

   Передается запрос с названием сессии, ее идентификатором и общим секретом для аттестации.

7. CAS → TEE

   В ответ CAS отправляет секрет, который используется TEE для дальнейшего взаимодействия с другими TEE.

Процесс формирования сессии между анклавами

1. Формируется инициализирующая Сессия, которая заполняется рандомными значениям
   • id,
   • key,
   • iv
2. Сессия сериализуется в 2 заголовка:
   • session_id - не шифруется
   • session_data - шифруется ключом от hmac (session_id, shared_secret)
3. Внешний анклав получает эти заголовки и имея session_id, shared_secret может расшифровать session_data = {id, key, iv} -> появилась сессия с другим анклавом. Сторонний анклав может сформировать ответ и передать его в зашифрованном виде (key, iv)

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

При отправке модели на согласование, все части модели: витрина и скрипт должны пройти согласование согласно процессу Согласование модели.

При этом происходит процесс согласования скрипта модели. Технически согласование скрипта каждой модели происходит согласно схеме. Информация о скрипте и факте его согласования передается посредством Blockchain таблицы Messages. Т.к. Blockchain используется для обмена сообщениями, сообщения обновляются при согласовании. При этом сам скрипт не меняется в процессе согласования. На момент отправки скрипта на согласование, формируется подпись основанная на hash конктетного коммита и при дальнейшем запуске модели на основе этого скрипта проверяется эта подпись.

Передача архива со скриптом в процессе согласования скрипта передается посредством взаимодействия анклав-анклав.

При каждом запуске согласованной модели Cleanroom, исполнение модели происходит на стороне локального инстанса, то есть где запрошено исполнение модели.

Исполнение модели состоит из шагов:

1. Запрос данных для формирования витрины и формирование витрины

2. Исполнение согласованного скрипта

3. Выгрузка результата в ClickHouse.

На шаге 1 запрашиваются данные для формирования витрины данных (локальные и со сторонних инстансов). Передача данных происходит между анклавами согласно процессу, описанному на схеме по ссылке. Там описано как происходит выгрузка датасетов для формирования витрины, на данных которой происходит матчинг.

Сам алгоритм матчинга описан в разделе по ссылке.

Данные используемые при исполнении скрипта запрашиваются на первом шаге и доступны скрипту на шаге 2 в виде предсобранного файла внутри анклава. То есть сам скрипт данные не запрашивает.

Для взаимодействия анклавов между инстансами происходит их аттестация, которая описана в разделе по безопасности. Механизм аттестации анклавов общий для всех бизнес-операций, как для: матчинга витрин, выгрузки витрин на VM, исполнения модели Cleanroom. Результат исполнения скрипта в анклаве в рамках шага 3 записывается напрямую в ClickHouse.

Обеспечение безопасности VM

Контейнер VM использует Persistent Volume со storage class Longhorn в качестве rootfs. Все данные, помещенные на диск являются зашифрованными. Шифрование по умолчанию AES-256. Ссылка на описание от Longhorn.

Запрещены любые операции выгрузки информации с виртуальной машины на рабочее место сотрудника. На виртуальной машине закрыт доступ в сеть интернет. Копирование информации с виртуальной машины в локальное окружение пользователя запрещено, буфер обмена отключен. Не допускается подключение сторонних устройств. Доступ со стороны пользователя к виртуальной машине, как и к остальным компонентам системы, обеспечивается через https.

Взаимодействие VM с другими компонентами системы описано по ссылке.

В рамках инсталяции конкретного окружения определяется, какой GitLab использовать. Рекомендуется использовать отдельный GitLab, установленный на ряду с остальными компонентами системы, в этом случае доступ к нему обеспечивается только с VM и при помощи программного токена системы ADCP.

Отдельная регистрация событий на VM не ведется, т.к. любые операции по выгрузке данных в GitLab фиксируются в рамках GitLab. Так же, сами скрипты, публикуемые в GitLab при попытке использования проходят модерацию согласно процессу согласования модели.

note

Нужно понимать, что уровень защиты данных, попадаемых на ВМ ниже, чем при вычислениях в анклаве, даже с учетом шифрования разделов. Поэтому на ВМ рекомендуется выгружать лишь необходимый для обучения моделей фрагмент данных.

Доступ к виртуальной машине обеспечивается по jwt-token системы. Таким образом пользователь, не авторизованный и/или не состоящий в проекте, в рамках которого создана виртуальная машина, не может получить доступ к VM. В случае использования доменной аутентификации, безопасность входа так же обеспечивается разграничением доступа в систему при помощи доменных учетных записей.