Безопасность и соответствие требованиям

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

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

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

Да, применяется многоуровневый подход. На рабочих станциях сотрудников используются штатные и коммерческие средства антивирусной защиты с автоматическим обновлением баз и включенной защитой в реальном времени; установка ПО из непроверенных источников запрещена политикой. На серверах, работающих под управлением Linux в контейнеризованной среде, применяется модель минимальной поверхности атаки: используются только доверенные базовые образы, обязательна проверка целостности и антивирусное/уязвимостное сканирование дистрибутивов и артефактов до ввода в эксплуатацию, в конвейере CI/CD выполняется автоматическое сканирование контейнерных образов на известные уязвимости и вредоносное содержимое, доступ на серверы ограничен и осуществляется только через контролируемые каналы

Да. Периметр защищен межсетевым экраном, работающим по принципу «запрещено все, что явно не разрешено» (default deny). Наружу публикуются только необходимые для работы сервиса порты и протоколы; входящий трафик к веб-интерфейсам и API проходит через обратный прокси/балансировщик с терминацией TLS. Сеть сегментирована: отдельно выделены контур внешнего доступа, контур приложений, контур хранения данных (СУБД, брокер сообщений, кэш) и контур управления; межсегментное взаимодействие разрешено только по явно описанным правилам. Базы данных и внутренние сервисы не имеют прямого доступа из внешней сети. Административный доступ возможен только через VPN и/или хост. Правила межсетевого экранирования проходят периодический пересмотр на предмет актуальности.

Да. Удаленный доступ к инфраструктуре осуществляется только через VPN с взаимной аутентификацией по персональному клиентскому сертификату, выпущенному на конкретного сотрудника, в сочетании с учетными данными пользователя - то есть используются два независимых фактора (владение сертификатом/ключом и знание пароля). Доступ к серверам выполняется по персональным SSH-ключам, парольная аутентификация по SSH отключена. Для доступа к панелям управления, репозиториям кода и облачным консолям включена двухфакторная аутентификация (TOTP). Общих (разделяемых) учетных записей не используется, все действия персонифицированы. При увольнении или смене роли сертификаты и ключи отзываются в тот же рабочий день.

Да, действует процесс управления обновлениями и уязвимостями. Обновления операционных систем и системного ПО устанавливаются планово; отслеживание уязвимостей ведется по публичным источникам (CVE/NVD, бюллетени вендоров и сообществ используемых компонентов) и по результатам автоматического сканирования зависимостей и контейнерных образов в конвейере CI/CD, который запускается на каждую сборку и дополнительно по расписанию для уже опубликованных артефактов. Установлены целевые сроки устранения: критические уязвимости - в течение 24–72 часов с момента подтверждения, высокого уровня - до 14 дней, среднего - в рамках ближайшего планового релиза, низкого - по мере планового обновления. Сборка блокируется при наличии неустраненных уязвимостей уровня HIGH/CRITICAL. При невозможности немедленного обновления применяются компенсирующие меры (ограничение доступа, отключение функциональности, правила фильтрации) с фиксацией решения.

Да. Резервное копирование выполняется автоматически по расписанию. Для PostgreSQL используется схема «полная базовая копия + непрерывная архивация журналов транзакций (WAL)», что обеспечивает возможность восстановления на произвольный момент времени (PITR). Резервируются также конфигурации сервисов и инфраструктурный код. Копии хранятся в отдельном от продуктивной среды хранилище, передаются и хранятся в зашифрованном виде, доступ к ним ограничен отдельным набором учетных данных. Глубина хранения и целевые показатели RPO/RTO фиксируются в SLA по проекту. Работоспособность резервных копий проверяется регулярным тестовым восстановлением на изолированном стенде; результаты проверки фиксируются. Для аналитических и потоковых компонентов данные восстанавливаются переигрыванием событий из журнала брокера сообщений и повторной репликацией из источника.

Да. Действует Регламент реагирования на инциденты ИБ и ведется журнал учета инцидентов. Процесс включает этапы: обнаружение и регистрация (в том числе по обращениям сотрудников и заказчиков, срабатываниям мониторинга и алертам), первичная классификация по критичности и типу, локализация и сдерживание, устранение причины, восстановление штатной работы, разбор с фиксацией причин и корректирующих мер. За каждым инцидентом закрепляется ответственный. Для инцидентов, затрагивающих данные или сервисы заказчика, предусмотрено уведомление уполномоченного контактного лица заказчика в согласованный договором срок с последующим предоставлением отчета о расследовании и принятых мерах. Инфраструктура покрыта централизованным сбором логов и метрик с алертингом, что обеспечивает раннее обнаружение аномалий.

Не применимо. Компания не оказывает лицензируемых видов деятельности в области технической защиты конфиденциальной информации и не осуществляет разработку и производство средств защиты информации - поставляемый продукт является прикладным программным обеспечением (платформа CDP и процессинга лояльности), а не средством защиты информации. Соответственно, требование о наличии лицензии ФСТЭК к нашей деятельности не относится. При этом компания аккредитована Минцифры России как ИТ-организация, а программный продукт включен в Единый реестр российских программ для ЭВМ и баз данных (запись № 17777). В случае, если в рамках проекта потребуется применение сертифицированных средств защиты информации, они применяются на стороне инфраструктуры заказчика или закупаются у лицензиатов ФСТЭК.

Безопасность встроена в конвейер разработки как обязательный, а не рекомендательный этап. Используется trunk-based/feature-branch модель с обязательным code review: изменения попадают в основную ветку только через pull request с ревью минимум одного другого разработчика; прямая запись в основную ветку запрещена. На каждый pull request автоматически запускаются: статический анализ кода (SAST), анализ состава и уязвимостей сторонних зависимостей (SCA), сканирование контейнерных образов, поиск секретов и учетных данных в коде и истории коммитов, а также модульные и интеграционные автотесты. Уязвимости уровня HIGH и CRITICAL блокируют сборку - артефакт не может быть собран и опубликован в репозиторий до их устранения; находки уровней MEDIUM/LOW регистрируются и планируются к устранению. Среды разработки, тестирования и продуктивной эксплуатации разделены; разработчики не имеют доступа к продуктивным данным, в тестовых средах используются синтетические или обезличенные данные. Артефакты версионируются и публикуются в приватный реестр, развертывание выполняется только из подписанных/проверенных артефактов через контролируемый пайплайн.

Выделенной штатной AppSec-команды в компании нет - это обусловлено размером организации. Функция реализована распределенно и компенсирована процессно: ответственность за безопасность разрабатываемого продукта закреплена за техническим руководителем, который фактически исполняет роль Security Champion - согласует требования безопасности к архитектуре, проводит ревью критичных с точки зрения ИБ изменений (аутентификация, авторизация, работа с ПДн, интеграции), контролирует разбор находок сканеров. Тимлиды отвечают за соблюдение стандартов безопасного кодирования в своих зонах. Обязательные автоматизированные проверки в CI/CD компенсируют отсутствие отдельной команды, обеспечивая контроль независимо от человеческого фактора. Для отдельных задач (пентест, аудит архитектуры) привлекаются внешние специалисты. В рамках проекта с заказчиком готовы формально назначить ответственного Security Champion со стороны проектной команды и включить его в контур взаимодействия со службой ИБ заказчика.

Да, требования ИБ учитываются на каждом этапе. На этапе анализа требований фиксируются требования к ролевой модели и разграничению доступа, к составу и категориям обрабатываемых данных (включая ПДн), к журналированию значимых действий. На этапе проектирования для существенных изменений выполняется анализ угроз и рисков: определяются доверительные границы, точки входа, необходимость шифрования и валидации. На этапе реализации применяются внутренние стандарты безопасного кодирования и обязательное code review. На этапе тестирования выполняются автоматические проверки SAST/SCA/сканирование образов, а также функциональные тесты разграничения доступа. Перед приемкой релиз проходит чек-лист готовности, включающий пункты по безопасности (отсутствие неустраненных HIGH/CRITICAL, актуальность зависимостей, корректность конфигураций и секретов). На этапе эксплуатации действуют мониторинг, патч-менеджмент и процесс реагирования на инциденты.

Да. Статический анализ интегрирован в CI/CD и запускается автоматически на каждый pull request и на каждую сборку - запуск не зависит от решения разработчика. Для основного языка разработки (nodejs,Go) применяются линтеры и анализаторы безопасности, выявляющие небезопасные конструкции, ошибки обработки ошибок, потенциальные инъекции, небезопасную работу с криптографией и файловой системой. Для фронтенд- и служебного кода (TypeScript/JavaScript) применяются анализаторы с наборами правил безопасности. Дополнительно выполняется автоматический поиск секретов, паролей и токенов в коде и истории репозитория. Находки уровня HIGH/CRITICAL приводят к падению сборки (блокирующий gate); прочие находки регистрируются и планируются к устранению. Результаты анализа доступны в истории пайплайна и могут быть предоставлены заказчику по релизу.

Да, применяются оба класса инструментов. SCA выполняется автоматически на каждой сборке: анализируется полный граф зависимостей (прямых и транзитивных) по манифестам и lock-файлам, а также содержимое итоговых контейнерных образов, включая пакеты базового слоя ОС; выявленные известные уязвимости сопоставляются с базами CVE, уровни HIGH/CRITICAL блокируют публикацию артефакта. Дополнительно контролируется лицензионная чистота используемых компонентов. DAST выполняется на тестовом стенде, развернутом в конфигурации, приближенной к продуктивной: сканируются веб-интерфейсы и HTTP API на типовые уязвимости (инъекции, XSS, некорректная авторизация, небезопасные заголовки и конфигурации, раскрытие информации в ошибках) перед мажорными релизами и при существенных изменениях внешних интерфейсов. Находки регистрируются и устраняются в соответствии с установленными сроками.

Да. Тестирование защищенности проводится силами внутренних специалистов: выполняется проверка ролевой модели и разграничения доступа (в том числе попытки горизонтального и вертикального повышения привилегий), проверка механизмов аутентификации и управления сессиями, контроль обработки входных данных, инструментальное сканирование внешнего периметра и веб-интерфейсов. Проверки выполняются перед мажорными релизами и при изменении внешних интерфейсов; сценарии безопасности покрыты автоматизированными тестами, выполняющимися регулярно в составе CI/CD. Независимый внешний пентест на постоянной основе не проводится. При этом мы готовы предоставить заказчику или привлеченной им организации доступ к стенду, развернутому в рамках проекта, для проведения независимого тестирования на проникновение, принять отчет по его результатам и устранить выявленные недостатки в согласованные сроки в рамках проекта - такой формат мы применяли в проектах с финансовыми организациями.

Помимо перечисленных SAST/SCA/DAST и внутренних проверок защищенности, дополнительно выполняются: автоматический поиск секретов и учетных данных в исходном коде и истории репозитория; сканирование контейнерных образов и инфраструктурного кода на небезопасные конфигурации; периодический пересмотр прав доступа к репозиториям, средам и данным; нагрузочное тестирование ключевых компонентов, подтверждающее устойчивость к пиковым нагрузкам и снижающее риск отказа в обслуживании. Специализированные виды тестирования (фаззинг, реверс-инжиниринг, threat hunting) на регулярной основе не проводятся - при наличии требования заказчика такие работы могут быть организованы с привлечением профильных подрядчиков.

Да, действует внутренний регламент управления уязвимостями. Уязвимости классифицируются по уровню критичности (по шкале CVSS с учетом фактической эксплуатируемости в нашей архитектуре и наличия компенсирующих мер). Установлены целевые сроки: CRITICAL - подтверждение и начало работ в течение 24 часов, устранение или ввод компенсирующих мер в течение 72 часов; HIGH - до 14 календарных дней; MEDIUM - в рамках ближайшего планового релиза; LOW - в плановом порядке. Уязвимости уровня HIGH/CRITICAL блокируют сборку и публикацию релиза. По каждой уязвимости фиксируется источник обнаружения, ответственный, принятое решение и дата устранения. Сроки устранения для поставляемого заказчику ПО могут быть зафиксированы в SLA договора и приведены к требованиям заказчика.

Да. Разработчики проходят обучение по безопасной разработке с опорой на OWASP Top 10 и классификацию CWE: типовые уязвимости веб-приложений и API, безопасная работа с СУБД и параметризация запросов, корректная реализация аутентификации и авторизации, безопасное обращение с секретами и криптографией, валидация и нормализация входных данных, безопасное журналирование без раскрытия чувствительных сведений. Обучение/передача знаний проводится при выходе новых сотрудников и периодически для всей команды. Дополнительно применяется практико-ориентированный формат: находки статических анализаторов и результаты code review разбираются командой как учебные кейсы, что закрепляет знания на реальном коде продукта. Внутренние стандарты безопасного кодирования зафиксированы документально и доступны всем разработчикам.

Да. Платформа поддерживает многофакторную аутентификацию для пользователей административных интерфейсов. Реализована поддержка одноразовых кодов (TOTP) как второго фактора. Кроме того, поддерживается интеграция с корпоративными системами аутентификации заказчика по стандартным протоколам (OIDC/OAuth 2.0, SAML 2.0, LDAP/Active Directory), что позволяет использовать штатные средства MFA и парольные политики заказчика, а также централизованно управлять жизненным циклом учетных записей. Дополнительно реализованы: ролевая модель доступа (RBAC), политики сложности и срока действия паролей, ограничение числа неуспешных попыток входа с временной блокировкой, контроль времени жизни сессий и принудительное завершение сессии, журналирование событий входа. Конкретная конфигурация согласуется на этапе внедрения.

Да. Весь внешний трафик к веб-интерфейсам и API передается исключительно по HTTPS с использованием TLS 1.2 и TLS 1.3; устаревшие протоколы (SSLv3, TLS 1.0/1.1) и слабые наборы шифров отключены, применяются наборы с прямой секретностью (PFS), включен HSTS, HTTP-трафик принудительно перенаправляется на HTTPS. Взаимодействие с внешними системами и интеграционные вызовы также выполняются по TLS. Внутреннее взаимодействие компонентов происходит в изолированном сетевом сегменте; для соединений с СУБД, брокером сообщений и кэшем применяется шифрование канала, а при требовании заказчика - взаимная аутентификация сторон (mTLS). При хранении применяется шифрование на уровне томов/дисков и файловых систем, резервные копии хранятся и передаются в зашифрованном виде. Чувствительные поля дополнительно защищаются на уровне приложения

Да. Помимо шифрования канала и хранилища, чувствительные данные защищаются на уровне приложения. Пароли пользователей не хранятся в открытом или обратимом виде - хранятся только необратимые хеши со случайной солью. Учетные данные для внешних интеграций, ключи API и токены хранятся в защищенном хранилище секретов, не попадают в исходный код и конфигурационные файлы репозитория, доступны сервисам только на этапе исполнения и подлежат ротации. Чувствительные атрибуты подписчиков и клиентов (контактные данные, идентификаторы) обрабатываются с разграничением доступа на уровне ролей: пользователи, которым эти сведения не требуются, видят их в маскированном виде. В журналах и трассировках чувствительные данные маскируются либо не записываются вовсе; передача полных значений в системы мониторинга исключена. При необходимости может быть реализовано шифрование отдельных полей в СУБД с управлением ключами на стороне заказчика - состав таких полей определяется на этапе проектирования интеграции.

Да. Пароли учетных записей хранятся исключительно в виде необратимых хешей, вычисленных с помощью специализированных алгоритмов, устойчивых к подбору на специализированном оборудовании, с уникальной солью для каждой записи и с параметрами сложности, соответствующими актуальным рекомендациям. Обратное восстановление пароля невозможно - предусмотрена процедура сброса с выдачей одноразовой ссылки/кода ограниченного срока действия. Реализованы политика сложности паролей, ограничение числа неуспешных попыток аутентификации с временной блокировкой учетной записи и защита от автоматизированного перебора. При использовании внешнего провайдера аутентификации (SSO) пароли на стороне платформы не хранятся вовсе.

Да, защита реализована по каждой категории OWASP Top 10. Нарушение контроля доступа: ролевая модель с проверкой прав на стороне сервера при каждом запросе, проверка принадлежности объекта запрашивающему субъекту (защита от IDOR), изоляция данных между арендаторами/подразделениями. Инъекции: работа с СУБД только через параметризованные запросы и подготовленные выражения, строгая типизация и валидация входных данных по схеме, экранирование при формировании запросов и вывода. XSS: экранирование вывода, использование фреймворков с автоматическим экранированием, политика CSP, флаги HttpOnly/Secure/SameSite для cookie. CSRF: применение анти-CSRF токенов и/или аутентификация по заголовку с токеном вместо cookie. Криптографические сбои: TLS, стойкое хеширование паролей, защищенное хранилище секретов. Небезопасная конфигурация: минимизация состава образов, отключение отладочных режимов и служебных эндпойнтов в продуктивной среде, безопасные HTTP-заголовки, отсутствие технической информации в сообщениях об ошибках. Уязвимые компоненты: SCA-контроль зависимостей. Ошибки аутентификации: политики паролей, MFA, контроль сессий. Недостаточное журналирование: аудит значимых действий с централизованным сбором логов и алертингом. Дополнительно применяются ограничение частоты запросов (rate limiting) и лимиты на размер запросов для защиты от злоупотреблений.

Да. При загрузке файлов (импорт клиентских данных через файлы) применяется комплекс мер: ограничение максимального размера файла и количества загрузок; проверка расширения и MIME-типа по «белому списку» разрешенных форматов с дополнительной проверкой фактической сигнатуры содержимого файла, а не только заявленного типа; принудительное переименование файла с генерацией собственного идентификатора и отбрасыванием пользовательского имени и пути (защита от path traversal); хранение загруженных файлов вне каталогов веб-сервера - в объектном хранилище или выделенном каталоге без прав на исполнение; отдача файлов только через контролируемый эндпойнт с проверкой прав доступа и корректными заголовками (Content-Disposition, X-Content-Type-Options), исключающими исполнение содержимого в браузере. Загруженные файлы проверяются антивирусными средствами до обработки (если такие установлены на сервере); Для структурированных импортов дополнительно выполняется валидация схемы и содержимого перед загрузкой в хранилище.

Да. Состав сторонних компонентов фиксируется декларативно в манифестах и lock-файлах систем сборки, что обеспечивает воспроизводимость сборки и точный учет версий, включая транзитивные зависимости. На каждый релиз автоматически формируется перечень компонентов (SBOM) с указанием наименований, версий и лицензий; перечень сохраняется вместе с артефактом релиза. Реестр компонентов используется для оперативной оценки применимости вновь опубликованных уязвимостей: при появлении новой CVE мы определяем, затрагивает ли она поставляемые версии. Добавление новых зависимостей проходит через code review с оценкой необходимости, активности сопровождения компонента и лицензии.

Да. Сборка артефактов выполняется только автоматизированным конвейером CI/CD из зафиксированного состояния репозитория - ручная сборка и загрузка артефактов «в обход» пайплайна запрещены. Контейнерные образы публикуются в приватный регистри с ограниченным доступом; используются неизменяемые теги, а развертывание выполняется с привязкой к криптографическому дайджесту образа (digest), что исключает подмену содержимого при неизменном теге. Для передаваемых заказчику дистрибутивов формируются и публикуются контрольные суммы (SHA-256), позволяющие проверить целостность на приемной стороне; при требовании заказчика применяется криптографическая подпись артефактов с предоставлением открытого ключа для верификации. Базовые образы и внешние зависимости загружаются из доверенных источников с проверкой целостности.

Да. Порядок информирования определен внутренним регламентом и фиксируется в договоре/SLA. При выявлении уязвимости, затрагивающей поставленную заказчику версию продукта, уполномоченное контактное лицо заказчика уведомляется в согласованный срок (для критических уязвимостей - незамедлительно, в пределах согласованного окна). Уведомление содержит описание уязвимости и затронутых компонентов и версий, оценку уровня критичности и потенциального воздействия, наличие признаков эксплуатации, рекомендованные компенсирующие меры до выпуска исправления, план и сроки выпуска обновления. После выпуска обновления предоставляются инструкция по установке, описание изменений и, при необходимости, поддержка при обновлении. Информация о выпущенных обновлениях безопасности сопровождает каждый релиз в составе release notes.

Сертификатов соответствия ФСТЭК/ФСБ России на продукт не имеется, поскольку продукт не является средством защиты информации и не реализует собственных криптографических функций, подлежащих обязательной сертификации: криптографическая защита канала обеспечивается штатными механизмами TLS на уровне системного ПО и инфраструктуры. Продукт представляет собой прикладную платформу управления клиентскими данными и программами лояльности. Продукт включен в Единый реестр российских программ для ЭВМ и баз данных (запись № 17777), компания имеет аккредитацию Минцифры России как ИТ-организация. При наличии у заказчика требования применять сертифицированные средства криптографической защиты (СКЗИ) в контуре размещения платформы, такие средства применяются на стороне инфраструктуры заказчика; платформа совместима с работой за терминирующими TLS/СКЗИ-шлюзами и не препятствует их использованию.

Да. Платформа реализует технические меры, соответствующие составу мер приказа ФСТЭК России № 21, в части, относящейся к прикладному программному обеспечению. Идентификация и аутентификация субъектов доступа: персонифицированные учетные записи, парольная политика, поддержка MFA и интеграции с системами аутентификации заказчика. Управление доступом: ролевая модель с назначением минимально необходимых прав, разграничение доступа к данным на уровне объектов и атрибутов, процедуры предоставления и отзыва прав. Регистрация событий безопасности: журналирование входов, изменений прав, доступа к персональным данным и их выгрузки, изменений конфигурации, с защитой журналов от модификации и централизованным хранением. Защита машинных носителей и среды: шифрование каналов и хранилищ, резервное копирование. Контроль целостности: проверка целостности артефактов и конфигураций. Обеспечение доступности: резервирование, мониторинг, процедуры восстановления. Дополнительно реализованы функции, необходимые для выполнения требований 152-ФЗ: обезличивание и маскирование данных, удаление данных субъекта по запросу, ограничение сроков хранения. Меры на уровне инфраструктуры (антивирусная защита, обнаружение вторжений, сегментирование, защита среды виртуализации) реализуются совместно с заказчиком в зависимости от модели размещения (в контуре заказчика или в облаке).

Среда настройки процессов является конфигурационной, а не средой программирования общего назначения: пользователь не пишет произвольный код, а собирает сценарий из предопределенного набора типовых узлов (условия, сегментация, начисление/списание баллов, отправка коммуникации, интеграционный вызов), каждый из которых реализован и протестирован разработчиками платформы. Настройка возможна только в рамках разрешенных для конкретного узла параметров, значения которых проходят валидацию по схеме - задать произвольную операцию или обратиться к произвольному ресурсу через конфигурацию невозможно. Доступ к среде настройки разграничен ролями: разделены права на создание/редактирование черновика сценария, его согласование и публикацию в продуктивную среду; публикация выполняется отдельной ролью с повышенными полномочиями. Все изменения сценариев версионируются, сохраняется история с указанием автора и времени, доступен откат к предыдущей версии; события создания, изменения и публикации фиксируются в журнале аудита. Перед публикацией сценарий может быть проверен на тестовом контуре и на ограниченной выборке аудитории. На исполнение сценариев наложены ресурсные ограничения (частота срабатываний, объем обрабатываемой аудитории, лимиты на начисления), исключающие как непреднамеренные, так и злонамеренные массовые операции. Интеграционные вызовы возможны только к заранее зарегистрированным администратором эндпойнтам («белый список»), задать произвольный внешний адрес из интерфейса настройки нельзя.

Изоляция обеспечивается на двух уровнях:

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