Настоящий Обзор безопасности описывает технические и организационные меры, которые Melaya Labs LLC («Melaya») в настоящее время применяет для защиты конфиденциальности, целостности и доступности платформы Melaya. Он призван дать потенциальным и действующим пользователям, корпоративным покупателям и аудиторам честное представление о том, что находится в производстве сегодня, что находится в разработке и что ещё не реализовано. Если возможность является перспективной или находится в разработке, это явно отмечено, а не скрыто за расплывчатыми формулировками. Безопасность является общей ответственностью: Melaya отвечает за безопасность платформы, а клиенты отвечают за безопасность того, что они создают, загружают и выполняют на ней.
1. Шифрование при передаче и хранении данных
Все данные, передаваемые между клиентами и Сервисами, защищены протоколом Transport Layer Security (TLS) версии 1.2 или выше с терминацией на Cloudflare на периметре развёртывания. Производственный профиль TLS соответствует руководству Mozilla Intermediate compatibility: только TLS 1.2 и 1.3, только шифронаборы ECDHE, только прямо-секретные шифры AEAD, HSTS со значением max-age два года и директивой preload, а также строгая политика безопасности контента с явным списком разрешённых источников connect-src. Политика безопасности контента применяется на обоих уровнях: API-сервер устанавливает default-src 'none' через посредника безопасных заголовков, а публичное веб-приложение применяет политику, разрешающую наши собственные серверные части, а также провайдеров платежей и входа в систему, блокирующую плагиновый контент и перехват базового тега или атрибута form-action, и ограничивающую выполнение скриптов таким образом, что внедрённый скрипт не может передать данные на ресурс злоумышленника. Полный профиль TLS, зафиксированный список шифров и квартальный цикл проверки задокументированы в руководстве TLS Baseline во внутреннем хранилище безопасности. Внутренние вызовы между сервисами в рамках нашей инфраструктуры осуществляются через петлевые или частные сетевые каналы.
Шифрование данных в состоянии покоя реализовано на уровне приложения посредством конвертного шифрования на уровне полей. Полнотомное шифрование диска на уровне хранилища ещё не включено: производственные блочные устройства в настоящее время не зашифрованы на уровне диска. Шифрование на уровне томов с использованием LUKS выбрано в качестве пути устранения недостатка и является утверждённым пунктом дорожной карты безопасности. До его исполнения Melaya не представляет шифрование на уровне диска или шифрование томов, управляемое провайдером, как действующий контроль.
Чувствительные значения защищены слоем конвертного шифрования на уровне приложения, реализованным в нашем сервисе конвертного шифрования. Учётные данные API бирж (ключ, секрет, парольная фраза), учётные данные коннекторов на уровне пользователя и токены OAuth, а также секреты MFA и коды восстановления обёртываются с помощью AES-256-GCM с использованием 256-битного мастер-ключа, хранимого исключительно в серверном процессе, прежде чем они отправляются провайдеру хранилища Infisical или записываются в резервную таблицу agents.credentials. Формат передачи содержит явный идентификатор ключа (v1:<kid>:<base64(iv|ciphertext|tag)>), что позволяет серверу принимать несколько действительных ключей в течение окна ротации и направлять операции чтения к ключу, которым обёрнуто каждое значение. Новые записи всегда используют активный ключ, который является первой записью в настроенном списке ключей. Ротация представляет собой трёхвыпускную процедуру, которая никогда не останавливает платформу: добавьте новый ключ вторым (записи по-прежнему идут к старому ключу, новый ключ доступен только для чтения), продвиньте его на первую позицию (записи переключаются на новый ключ, старый остаётся читаемым), повторно оберните исторические строки, привязанные к идентификатору отставного ключа, затем удалите старую запись. Ни Infisical, ни хост Postgres не видят учётные данные в открытом тексте ни в какой момент: компрометация любого из субпроцессоров в отдельности даёт только зашифрованный текст, и злоумышленнику дополнительно требуется настроенный ключ конверта, чтобы восстановить какой-либо биржевой ключ. Одноразовый скрипт миграции обработал остаточные строки с открытым текстом из периода до появления слоя конверта. Миграция была выполнена на производственной базе данных, и её сквозной верификатор (envelope-verify.ts, 7/7 сценариев) завершается с нулевым кодом при каждом запуске CI и на живой производственной среде.
2. Изоляция арендаторов и конвейеров
Платформа обеспечивает логическую изоляцию между арендаторами на уровне приложения. Каждый аутентифицированный запрос содержит идентификатор пользователя, полученный из валидированного JSON Web Token, а каждый запрос к базе данных, доступ к объектному хранилищу и поиск в индексе поиска ограничены этим идентификатором через параметризованный SQL и контекстную цепочку tRPC. Поисковые индексы, созданные для Agentic Framework, хранятся в разбивке по конвейерам и возвращаются только запросам, исходящим от конвейера, которому они принадлежат. Состояние движка, конфигурации стратегий и истории ордеров также разделены по пользователям. Защита на уровне строк Postgres применяется в качестве дополнительного уровня глубокой защиты поверх изоляции на уровне приложения: FORCE ROW LEVEL SECURITY активна в производственной среде по 44 таблицам в схемах agents.* и cex.* в рамках 117 политик защиты на уровне строк, а приложение подключается под выделенной ролью с минимальными привилегиями, которая выполняется с NOBYPASSRLS и поэтому не может видеть данные других арендаторов даже в случае, если в запросе случайно пропущено условие WHERE user_id. Контекст защиты на уровне строк для каждого запроса устанавливает идентификатор арендатора и роль в качестве параметров сессии до выполнения любого запроса, а пул соединений выполняет DISCARD ALL при освобождении, исключая перенос контекста между арендаторами. Семнадцать межарендаторских сценариев в нашем верификаторе rls-verify.ts завершаются с нулевым кодом возврата против живой базы данных при каждом запуске CI, включая случаи SELECT, INSERT, UPDATE, DELETE, переназначения владельца, обхода администратором, нулевого ряда без контекста и регрессии утечки контекста.
3. Управление ключами и секретами
Секреты приложения, ключи подписи, учётные данные базы данных и сторонние API-ключи, используемые самим Melaya, хранятся в контролируемом оператором файле секретов, загружаемом при запуске процесса, а также в нашем провайдере хранилища. Они никогда не фиксируются в системе контроля версий, а производственные значения не передаются между разработчиками. Ключ конвертного шифрования является выделенным ключом шифрования, хранимым исключительно в хранилище секретов оператора, отдельно от учётных данных базы данных Postgres и отдельно от токена хранилища Infisical, поэтому компрометация любого одного из трёх не раскрывает биржевые учётные данные в открытом виде. Клиентам настоятельно рекомендуется ограничивать каждый API-ключ биржи разрешениями только на торговлю, отключать вывод средств на стороне биржи-эмитента и применять белый список IP-адресов там, где биржа это поддерживает.
Токены сессии подписываются в рамках многоключевого окна ротации. Сервер принимает упорядоченный набор ключей подписи, каждый из которых помечен коротким идентификатором. Новые токены подписываются первым (активным) ключом и несут этот идентификатор в заголовке JWT для верификации за O(1). Токены, выпущенные под любым отставным ключом в окне, продолжают проходить верификацию до истечения их семидневного TTL, после чего отставной ключ может быть удалён. Просроченные токены отклоняются немедленно, даже если неактивный ключ в иных условиях принял бы их. Циклы верификации зафиксированы в нашем верификаторе jwt-keys-verify.ts.
4. Аутентификация и контроль доступа
Аутентификация пользователей основана на адресе электронной почты и пароле с хэшированием bcrypt при рабочем факторе 12, в сочетании с ограничением частоты запросов на конечных точках входа, регистрации и восстановления пароля (20 попыток с одного IP за 15 минут, обеспечивается распределённым ограничителем на базе Redis). Токены сессии выдаются в виде JSON Web Tokens со сроком действия семь дней и привязаны к утверждениям пользователя, роли и тарифа. Управление доступом на основе ролей разграничивает user и admin, а управление доступом на основе тарифа ограничивает функции согласно каталогу четырёх тарифов. Каждое значимое действие проверяется на стороне сервера. Ограничения на стороне клиента служат исключительно подсказкой для пользовательского интерфейса и никогда не используются в целях безопасности.
Двухфакторная аутентификация доступна всем пользователям через стандартный профиль TOTP (RFC 6238, SHA-1, 6 цифр, период 30 секунд, допуск дрейфа ±1 окно) и совместима со всеми распространёнными приложениями-аутентификаторами. Общие секреты TOTP генерируются на стороне сервера с энтропией 160 бит, оборачиваются через слой конвертного шифрования, описанный в разделе 1, и хранятся в обёрнутом столбце в строке пользователя. Коды восстановления генерируются однократно при регистрации, хэшируются bcrypt с рабочим фактором 12, а затем повторно оборачиваются слоем конверта, так что компрометация базы данных в одиночку не позволяет их восстановить. Регистрация представляет собой двухэтапный процесс, в котором пользователь обязан подтвердить, что настроил приложение-аутентификатор, введя действующий код, прежде чем второй фактор будет отмечен активным. Процесс входа включает проверку пароля, затем кратковременный (пять минут) токен задачи, затем верификацию кода, которая атомарно потребляет строку задачи. Перехваченный токен задачи не может быть воспроизведён после успешного потребления. MFA обязательна при добавлении учётных данных API CEX и при генерации API-ключей платформы, двух действий с наибольшим воздействием на средства. Каждый результат задачи MFA (mfa.challenge_issued, mfa.challenge_ok, mfa.challenge_fail) записывается в журнал аудита только с добавлением, описанный в разделе 6, так что схемы задач поддаются аудиту и защищены от подделки.
Доступ сотрудников Melaya к производственным системам предоставляется индивидуально каждому инженеру в рамках задокументированного рабочего процесса двойного согласования и аннулируется, когда он больше не требуется. Предоставление доступа требует одобрения лица, отличного от запрашивающего, а процедура увольнения деактивирует учётную запись, ротирует ключи подписи JWT для аннулирования активных сессий, отзывает API-ключи и удаляет SSH-ключи. Устаревшие привилегированные записи sudoers и авторизованные SSH-ключи очищаются в рамках каждой сессии, а квартальный цикл проверки доступа задокументирован. Полное разграничение между пользователем развёртывания и пользователем среды выполнения сервиса (чтобы скомпрометированный процесс сервиса не мог перейти к пути развёртывания) отслеживается как запланированный контроль в дорожной карте безопасности.
5. Сетевое ограничение частоты запросов и инфраструктура
Ограничение частоты запросов применяется на уровне приложения через общее хранилище на базе Redis, что делает лимиты глобальными для всех серверных экземпляров, а не на уровне отдельных процессов. Применяются два независимо настроенных ведра: строгое ведро на конечных точках аутентификации (20 попыток с одного IP за 15-минутное окно) и общее ведро API (200 запросов с одного IP в минуту). Ограничитель работает по принципу «отказ при сбое»: если хранилище Redis недоступно, конечные точки аутентификации отклоняют запросы, а не пропускают их. Обёртка ограничителя, поддерживающая пакетную обработку tRPC, проверена нашим верификатором rate-limit-verify.ts (7/7 сценариев, включая атаку обхода через пакетный запрос).
Граничный трафик обрабатывается Cloudflare с WAF, обнаружением ботов и геоблокировкой на путях высокого риска. Шаблон Terraform для зоны Cloudflare зафиксирован вместе с операционным руководством, охватывающим обнаружение расхождений, аварийное переключение и правило сверки через 24 часа. Импорт и сверка текущей зоны, настраиваемой вручную, с этим шаблоном выполняются в настоящее время и являются блокирующей задачей перед назначением первого внешнего теста на проникновение.
6. Мониторинг, журналирование и аудит
Платформа формирует структурированные журналы от сервера tRPC на Node.js, Rust Engine, Python-воркера и граничного уровня. Все журналы уровня хоста и контейнера (журнал systemd, системные журналы хоста, журналы доступа и ошибок nginx, стандартный вывод CI и контейнеров source-forge, а также все журналы приложений Melaya) вывозятся с хоста в режиме реального времени в арендаторский раздел Grafana Cloud Loki в том же регионе, что и производственный хост, через коллектор Grafana Alloy, поэтому след аудита сохраняется даже в случае компрометации хоста или потери диска. Исходящие сетевые соединения регистрируются правилом ведения журнала исходящего трафика сетевого уровня и пересылаются в тот же вынесенный приёмник; этот исходящий трафик сегодня регистрируется и отслеживается, тогда как принудительное allowlisting исходящего трафика на основе запрета остаётся запланированным пунктом дорожной карты.
События, имеющие значение для безопасности (результаты аутентификации, результаты задач MFA, добавление и удаление учётных данных CEX, выдача и отзыв API-ключей платформы, изменения тарифа и откаты), дополнительно записываются в таблицу agents.audit_log только с добавлением. Схема отзывает UPDATE и DELETE у роли приложения, поддерживает криптографическую хэш-цепочку по строкам (prev_hash / row_hash), хранит IP-адрес субъекта только в виде хэша HMAC-SHA256 с ключом (не обычный SHA-256, уязвимый для словарных атак) и предоставляет вспомогательную таблицу agents.audit_log_tombstone для удаления по Статье 17 GDPR, которая никогда не изменяет цепочку. Ежедневный верификатор (verify-audit-chain.ts) обходит цепочку от начала до конца, проверяет монотонность меток времени с допуском NTP ±2 секунды и выдаёт якорный хэш, пригодный для внешнего хранилища только с записью. Шесть сценариев фальсификации в audit-log-verify.ts завершаются с нулевым кодом на живой производственной среде.
7. Управление уязвимостями
При каждом коммите в рамках CI выполняются npm audit --production и сканирование файловой системы Trivy. Trivy вызывается дважды при каждой сборке: один раз в блокирующем режиме с ignore-unfixed: true, чтобы обнаруженные уязвимости с доступными исправлениями приводили к сбою проверки, и один раз с ignore-unfixed: false в неблокирующем режиме, чтобы полная поверхность уязвимостей загружалась на вкладку безопасности репозитория в качестве доказательства соответствия. Производственный хост запускает unattended-upgrades с включённым каналом безопасности и автоматическим окном перезагрузки. Сторонние образы контейнеров для служб CI, source-forge, хранилища секретов, Postgres и Redis проходят проверку перед обновлением версий, отслеживаются в руководстве по периодическому применению исправлений во внутреннем хранилище безопасности и контролируются ежедневным детектором отклонений хэша образа, который выдаёт предупреждение в течение 24 часов после любой незаметной ротации образа.
Melaya ещё не прошла внешний тест на проникновение силами третьих лиц. Объём взаимодействия (включая активы в области применения и вне её, правила взаимодействия, краткий список поставщиков, требующий аккредитации CREST, и цикл устранения последствий после взаимодействия) зафиксирован во внутреннем руководстве Pentest Scope, чтобы выбор поставщика мог начаться сразу после завершения сверки IaC Cloudflare из раздела 5. В документации Melaya нигде не утверждается «ежегодный тест на проникновение».
8. Безопасная разработка программного обеспечения
Изменения платформы проходят через систему контроля версий с проверкой коллегами перед слиянием. Строгий режим TypeScript и статический анализ выполняются при каждой сборке клиента и сервера. gitleaks запускается как хук перед коммитом и в CI с ограниченным по пути списком разрешений, а не глобальным, так что случайное раскрытие учётных данных приводит к сбою сборки до слияния. Все действия CI закреплены хэшем коммита для предотвращения атак перезаписи тегов в цепочке поставок. Производственные развёртывания проходят через ограниченную обёртку Jenkins SSH с ограничением command= в authorized_keys, так что даже скомпрометированный CI-runner может вызывать только явные операции resync <service> и log <service> для разрешённых сервисов Melaya: без произвольного командного интерпретатора, без обхода файловой системы, без повышения привилегий за пределами перезапуска самого сервиса. Каждый вызов конвейера развёртывания журналируется за пределами машины в арендатора Grafana Cloud Loki для аудита вместе с зафиксированной записью о происхождении, связывающей работающий двоичный файл с его исходным коммитом.
9. Реагирование на инциденты
Melaya ведёт письменное руководство по реагированию на инциденты, охватывающее объявление серьёзности (четыре уровня серьёзности), распределение ролей (Командир инцидента, технический руководитель, специалист по коммуникациям, секретарь), контрольный список локализации с явными шагами ротации ключа конверта, ключа JWT и ключа IP-HMAC журнала аудита, матрицу уведомления за 72 часа по Статье 33 GDPR и шаблон разбора инцидента. Руководство зафиксировано во внутреннем хранилище безопасности и рассматривается как живой документ: первые настольные учения запланированы на 2026-07-15, и руководство явно помечено как «не активное» в собственных процедурах до проведения этих учений. Инженеры дежурной смены сегодня реагируют на реальные инциденты. Условие прохождения учений касается официальных настольных учений, а не наличия пути реагирования.
10. Резервное копирование и аварийное восстановление
Целевые показатели RTO и RPO на уровне подсистем опубликованы во внутреннем руководстве RTO RPO: уровень agents.* ориентируется на RTO 15 минут и RPO 2 часа, хранилище учётных данных CEX ориентируется на RTO 5 минут и RPO 1 час, Infisical и хранилище объектов ориентируются на RTO 4 часа и RPO 1 час, а Redis работает без резервного копирования и восстанавливается при переподключении. Механика резервного копирования объединяет непрерывное архивирование WAL с окном восстановления на определённый момент времени в 14 дней, ночной логический дамп, хранимый в другом регионе, ежемесячную базовую резервную копию и ежедневный экспорт якорного хэша журнала аудита только с записью во внешнее хранилище. Все артефакты резервного копирования сжаты, проверены контрольными суммами и зашифрованы с помощью restic. Проверка восстановления выполняется по двум циклам: автоматизированное еженедельное задание выполняет проверку целостности restic и выборочное восстановление в рабочий каталог, а первое полное учение по восстановлению в одноразовой среде запланировано на 2026-07-15, после чего его письменное подтверждение фактического времени восстановления и проверки целостности будет зафиксировано в том же руководстве. Сегодня Melaya работает из единственного первичного региона размещения. Это раскрыто прямо, а компенсирующие контроли (ночные дампы в другом регионе, непрерывное архивирование WAL, межрегиональный зонд работоспособности и DNS-переключение Cloudflare) ограничивают RTO при полной потере региона в наихудшем случае приблизительно 24 часами как задокументированный и принятый риск.
11. Непрерывность бизнеса
Письменный план непрерывности бизнеса зафиксирован во внутреннем хранилище безопасности и охватывает реагирование на отказ первичного региона, отказ провайдера Postgres, сбой хранилища Infisical (сервер продолжает обслуживать существующие сессии через кэшированные учётные данные, новые записи CEX отклоняются с видимой пользователю ошибкой), сбой Stripe (существующие подписки не затронуты), матрицу доступности персонала и таблицу плана действий по каждому поставщику. План пересматривается в тот же квартальный цикл, что и базовый уровень TLS, с ежегодным полным разбором в рамках настольных учений.
12. Безопасность поставщиков и субобработчиков
Melaya использует субобработчиков и поставщиков инфраструктуры для функций из общедоступного списка Субобработчиков. Договорную роль, местонахождение и гарантию передачи каждого поставщика следует оценивать по фактическому развёртыванию и соглашению; выбранные клиентом модели, коннекторы, продавцы или инструменты могут действовать по его инструкциям и своим условиям, а не по договорам Melaya с поставщиками. Корпоративные клиенты получают применимые права уведомления и возражения по своему соглашению или дополнению об обработке данных. Основная размещённая среда Melaya сейчас работает в Сингапуре, на который не распространяется решение ЕС об адекватности, поэтому применимые передачи требуют законного механизма и дополнительных гарантий, где необходимо. Локальная среда выполняет Python, локальные файлы, операции поиска и выбранные учётные данные на контролируемом клиентом оборудовании, но конфигурация, подписанное содержимое отправки, доставка выбранных учётных данных, события совместной работы, телеметрия, запросы облачным моделям или вызовы коннекторов всё равно могут проходить через Melaya или поступать Melaya и третьим лицам в выбранном режиме. Получателей и место хранения определяют общедоступная страница Субобработчиков, клиентское соглашение и фактический поток данных, а не одно лишь слово «локальный».
13. Статус соответствия
Melaya выстраивает свои контроли с учётом критериев доверительных услуг SOC 2 и стандарта ISO/IEC 27001. На дату настоящего документа Melaya НЕ имеет SOC 2 Type I, SOC 2 Type II, ISO/IEC 27001 или какой-либо эквивалентной сторонней аттестации безопасности, и ни одна проверка или оценка органом по сертификации не проводилась. Это перспективные ориентиры нашей дорожной карты. Любой потенциальный клиент, которому сегодня требуется аттестация, должен рассчитывать на получение анализа разрывов, а не готового отчёта. Корпоративные клиенты могут запросить нашу текущую матрицу контролей и список текущих мер по устранению недостатков, обратившись по адресу [email protected].
Шаблон Соглашения об обработке данных из пятнадцати разделов подготовлен и зафиксирован во внутреннем хранилище безопасности. Он включает Стандартные договорные условия Европейской комиссии (Модуль 2 для отношений контролёр-обработчик и Модуль 3 для отношений обработчик-обработчик), Дополнение к международной передаче данных Великобритании и эквивалент швейцарского FADP. Обязательство об уведомлении об утечке за 72 часа по статье 33 GDPR, процедура возврата или удаления данных и права на аудит (ограниченные ежегодным и конфиденциальным SOC 2 Type II после его получения) закреплены в шаблоне. Проверка внешними юристами ожидается до того, как Соглашение будет предложено в форме, принимаемой кликом, для платных тарифов и в виде версии для двустороннего подписания на тарифе Citadel.
14. Ответственность клиентов
Безопасность в Melaya является общей. Клиенты несут ответственность за выбор надёжных уникальных паролей, защиту своих учётных данных, ограничение API-ключей биржи минимально необходимыми разрешениями, проверку и валидацию поведения создаваемых конвейеров, контроль над контентом, загружаемым в индексы извлечения, ознакомление с условиями и практиками обработки данных любых сторонних провайдеров языковых моделей, через которых они маршрутизируют запросы, и незамедлительное сообщение о любой подозреваемой компрометации. Мы настоятельно рекомендуем включить двухфакторную аутентификацию в настройках аккаунта при первом входе; она обязательна перед добавлением любых учётных данных CEX или генерацией любого API-ключа платформы и является единственной наиболее эффективной мерой безопасности, которую клиент может применить к своему аккаунту.
15. Ответственное разглашение и безопасная гавань
Безопасная гавань. Melaya Labs LLC не будет преследовать в судебном порядке или поддерживать любые действия третьих сторон против исследователей безопасности, действующих добросовестно и соблюдающих настоящую политику. Это обязательство распространяется на требования, которые Melaya могла бы предъявить в соответствии с Законом США о компьютерном мошенничестве и злоупотреблениях (CFAA), Законом Великобритании о неправомерном использовании компьютеров, соответствующими положениями законов государств-членов ЕС о неправомерном использовании компьютеров, а также любыми гражданско-правовыми требованиями о нарушении договора, незаконном вмешательстве или вторжении в имущество. «Добросовестность» означает, что исследователь предпринял искренние усилия для соблюдения области применения и правил взаимодействия ниже, не получал доступ, не изменял, не уничтожал и не извлекал данные других пользователей, не деградировал намеренно Сервисы для других пользователей и сообщил о результатах в частном порядке по адресу [email protected] до любого публичного раскрытия. Это положение является обязательным для Melaya и не требует одобрения для каждого отчёта. Оно не распространяется на поведение, которое является независимо незаконным в юрисдикции исследователя, например, на фактическое финансовое мошенничество против других пользователей или вымогательство.
Область применения. Тестирование разрешено в отношении melaya.org и всех поддоменов в зоне *.melaya.org, поверхности приложения на app.melaya.org, конечных точек Builder API и юридических страниц Melaya. Тестирование НЕ разрешено в отношении: (i) размещения, отмены или изменения реальных ордеров на любой сторонней бирже, доступной через Melaya; (ii) сторонних провайдеров языковых моделей (OpenAI, Anthropic, Google, Cohere, локальные рантаймы), доступных через настроенный пользователем конвейер; (iii) самой инфраструктуры Cloudflare, провайдеров хостинга или хранилища; (iv) любых форм атак типа «отказ в обслуживании» (L3/L4 флуд, L7 флуд, подбор учётных данных в больших объёмах); (v) социальной инженерии сотрудников, подрядчиков или клиентов Melaya; (vi) физического проникновения.
Правила взаимодействия. Исследователи должны прекратить тестирование, как только находка доказана (одного неразрушающего чтения достаточно как доказательства межарендаторского доступа), никогда не изменять и не извлекать данные других пользователей, не устанавливать механизмы постоянного присутствия и поддерживать автоматизированное тестирование на уровне менее 1 запроса в секунду в среднем. Трафик тестирования должен содержать заголовок User-Agent: Melaya-research/<handle>, чтобы Melaya могла отличить его от реального трафика и не оповещала дежурного.
SLA по сортировке. Melaya обязуется подтверждать получение обоснованных отчётов в течение пяти (5) рабочих дней с момента получения, предоставлять первоначальную оценку серьёзности в течение десяти (10) рабочих дней с момента подтверждения и устранять выявленные недостатки в соответствии со шкалой серьёзности: Критический уровень в течение 48 часов, Высокий в течение 7 календарных дней, Средний в течение 30 календарных дней, Низкий в течение 90 календарных дней. Если Melaya нарушает обязательство по SLA, исследователь вправе направить письменное уведомление за семь (7) дней о намерении опубликовать материалы, и защита принципа «безопасной гавани» остаётся в силе до момента публикации при условии, что исследователь соблюдал правила взаимодействия на протяжении всего процесса.
Контакты. Отчёты следует направлять на [email protected]. PGP-ключ для зашифрованных отчётов будет опубликован на /.well-known/security.txt. Отчёты не следует направлять через социальные сети, задачи GitHub в публичных репозиториях Melaya или любые поверхности чата поддержки: эти каналы не отслеживаются для контента, связанного с безопасностью, и создают риск случайного публичного раскрытия до устранения уязвимости.
Настоящий Раздел 15 является самодостаточным, и его обязательства являются обязывающими. Защита «безопасной гавани» в первом пункте, область применения и правила взаимодействия во втором и третьем пунктах, SLA по сортировке в четвёртом пункте, А ТАКЖЕ правила взаимодействия с Условиями использования и правила изменений только в перспективе в следующем пункте вместе составляют полный набор обязательств, обязывающих Melaya в отношении исследователей безопасности. Каждый пункт в настоящем Разделе 15, а не только первые четыре, является частью обязывающего набора обязательств. Melaya ведёт внутреннее операционное руководство по маршрутизации и эскалации сортировки, но это руководство не добавляет, не убирает и не изменяет каких-либо обязательств в настоящем Разделе 15, и исследователю не нужно читать какой-либо другой документ, чтобы опираться на приведённую выше «безопасную гавань». Любые изменения в настоящем Разделе 15 применяются только в перспективе: находка, сообщённая добросовестно в соответствии с версией настоящего Раздела 15, действовавшей на момент подачи отчёта, остаётся защищённой «безопасной гаванью» этой версии независимо от любых последующих поправок.
Взаимодействие с Условиями использования (обязывающее). Настоящий Раздел 15 представляет собой явное разрешение Melaya на деятельность по исследованию безопасности, которая в противном случае была бы ограничена запретами Условий использования на обход, отключение или вмешательство в функции безопасности, ограничения частоты запросов или контроля доступа Melaya. Исследователь, действующий в рамках области применения и правил взаимодействия выше, следовательно, не нарушает Условия в отношении этих действий, и Melaya отказывается от любых требований, которые она могла бы предъявить в соответствии с Условиями в отношении этих конкретных действий. Настоящий пункт сам по себе является частью приведённого выше обязывающего набора обязательств и не является просто текстом толкования.
Модель безопасности Device Control
Device Control спроектирован как разрешённый пользователем и запрещённый по умолчанию канал. Приложение Android не может самостоятельно включить Специальные возможности или захват экрана; пользователь предоставляет эти разрешения в операционной системе. Для сборок, установленных вне магазина, Android может потребовать разрешения ограниченных настроек.
Сопряжённые телефоны аутентифицируются отзываемым токеном устройства, хранимым на сервере в виде хеша. Телефонные токены ограничены телефонными точками доступа, отделены от сеансов браузера и токенов сред выполнения и могут быть отозваны из учётной записи пользователя.
Доступ к приложениям обеспечивается списком разрешений. Сервер хранит разрешённые пользователем пакеты; телефон синхронизирует политику и проверяет приложение на переднем плане до чтения дерева экрана, допуска захвата, нажатий, ввода, прокрутки и иных ограниченных действий.
Кадры в реальном времени передаются через ретранслятор последнего кадра. Они не являются общими учётными данными и связаны только с каналом пользователя-владельца. Агентам следует запрашивать снимки, только если структурированных данных специальных возможностей недостаточно.
Нативное мобильное выполнение регистрирует одно активное выполнение для телефона пользователя. Средство остановки в наложении может прекратить только это зарегистрированное выполнение того же пользователя и не может прекращать произвольные процессы. Конечные состояния и состояния вмешательства человека возвращают пользователя в Melaya, сохраняя видимость контроля.
Меры защиты Мобильных агентов и выполнения на устройстве
Защита Мобильных агентов разделяет принятие решения, авторизацию, маршрутизацию и физическое выполнение. Модель или агент может предложить команду; сервисы Melaya проверяют аутентифицированного пользователя, статус сопряжённого телефона, политику действий и конверт команды; первый подходящий телефон, опросивший очередь, может получить задание из очереди пользователя; затем зарегистрированное и контролируемое пользователем устройство выполняет команду в пределах разрешений операционной системы.
Учётные данные устройства отделены от сеансов браузера, идентификаторов облачных сервисов, учётных данных поставщиков и токенов локальных сред. Сервер хранит SHA-256-хеш отзываемого токена телефона. Android сейчас хранит исходный токен в закрытых SharedPreferences, а iOS - в Связке ключей. Токен телефона не даёт права общего управления учётной записью, доступа к точкам телефона другого пользователя или несвязанной среде выполнения.
Команды по умолчанию запрещены и ограничены аутентифицированным пользователем, полученным заданием, политикой приложений, видом действия, параметрами и сроком нахождения в очереди. Очередь и список разрешений сейчас привязаны к пользователю, а не адресуются однозначно выбранному устройству при наличии нескольких сопряжённых телефонов; после получения задания проверка принадлежности связывает с ним результат. Чувствительные точки доступа аутентифицируют вызывающую сторону, проверяют размеры и принадлежность и отклоняют просроченные задания; клиентам следует сопрягать только доверенные устройства.
Неоднозначные действия или действия с существенными последствиями должны требовать нового подтверждения человеком, ясных сведений о цели и последствиях и доступной возможности приостановки или остановки. Постоянные индикаторы, наложения, уведомления фоновой службы, предварительный просмотр, сроки, ограничения частоты, журналы аудита и очистка конечного состояния обеспечивают многоуровневую защиту, но не гарантируют правильность или обратимость действия.
Каналы команд и телеметрии используют шифрованный транспорт и аутентифицированные идентификаторы. Подписанная или защищённая по целостности отправка, одноразовые значения, идентификаторы команд, срок действия, привязка к устройству и обнаружение повторов применяются, когда реализованы, чтобы снизить риск подмены и выполнения между пользователями. Транспортное шифрование не мешает авторизованной точке видеть открытые данные, необходимые для выполнения запроса.
Локальные среды сохраняют выполнение Python, локальные файлы и вывод локальной модели в среде пользователя с учётом средств контроля его операционной системы. Гибридные процессы дополнительно раскрывают нагрузки вывода или инструментов выбранным облачным поставщикам. Облачные процессы выполняются в управляемой Melaya инфраструктуре и могут обрабатывать данные выполнения и выбранные секреты. Изолирование снижает, но не устраняет риски приложений, зависимостей, моделей, внедрения инструкций или инфраструктуры.
Хранимые учётные данные защищаются шифрованием или средствами управления секретами и передаются только при их выборе для выполнения. Процесс выполнения и внешний поставщик неизбежно получают пригодные данные аутентификации. Пользователи обязаны применять минимальные привилегии, разделять производственные и тестовые данные, своевременно менять и отзывать их, ограничивать права поставщика и никогда не помещать секреты в запросы, снимки, журналы или ненадёжные результаты инструментов.
Сервисы телеметрии и совместной работы могут получать любые отправленные средой сообщения, трассировки, события и результаты инструментов, расходы, статусы, запросы подтверждения, снимки экрана или диагностические нагрузки. Клиенты должны надлежащим образом настраивать детализацию и хранение событий, избегать лишних чувствительных данных и применять контроль доступа к рабочей области и проекту. «Локальный» описывает место выполнения, а не гарантирует отсутствие переданной телеметрии.
Специальные возможности Android и MediaProjection являются чувствительными возможностями, предоставляемыми пользователем. До доступа мобильное приложение должно показать требуемое заметное уведомление и получить явное согласие, использовать наиболее узкий API, оставаться видимым, когда это требуется, ограниченно работать при отказе и никогда не обходить защиту платформы и не скрывать активность. Сборка Google Play не должна позволять Специальным возможностям автономно инициировать, планировать и выполнять действия в нарушение правил Google Play.
Приложение iOS из App Store ограничено изолированной средой, правами и общедоступными API Apple и не предоставляет неограниченного управления сторонними приложениями. Способы с использованием среды Mac, Режима разработчика, XCTest, WebDriverAgent, сопряжённого устройства или подписанного разработчиком тестирования имеют иную модель угроз и доверия и требуют контроля над Mac, удостоверением подписи, сопряжением устройства, целью тестирования и сетевым каналом.
Ни одна мера не устраняет все риски. Модели могут подвергаться манипуляциям через запросы или экран; приложения могут менять интерфейс; разрешения могут быть чрезмерными; зависимости могут быть скомпрометированы; устройства могут быть утрачены; авторизованные пользователи могут злоупотребить возможностями. Мы расследуем достоверные сообщения, вправе отозвать или изолировать затронутые учётные данные или устройства и рекомендуем немедленно применять процедуры остановки, отзыва, замены и сообщения об инцидентах.
16. Изменения в настоящем обзоре
Melaya может время от времени обновлять настоящий обзор безопасности, отражая изменения в платформе, наших контролях или субпроцессорах. Дата «Последнего обновления» в верхней части настоящего документа отражает наиболее актуальную редакцию. Когда запланированные пункты (такие как первое учение по восстановлению, первые настольные учения по реагированию на инциденты, первый внешний тест на проникновение, шифрование дисков на уровне томов или проверка шаблона DPA внешними юристами) будут выполнены, соответствующий раздел перепишется для отражения нового состояния, а изменение будет объявлено в журнале изменений продукта.
17. Контакты
По вопросам безопасности, отчётам об уязвимостях или для запроса документации о соответствии, пожалуйста, обращайтесь: