Инструкции по безопасности

Этот раздел перенесён из документации Camunda 7 и в дальнейшем будет доработан с учётом особенностей OpenBPM Engine

Эта страница предоставляет обзор способов обезопасить инсталлацию Camunda. Чтобы прочитать политики безопасности Camunda, ознакомиться со списком замечаний по безопасности и получить руководство по правилам сообщения об уязвимостях, обращайтесь к общей документации по безопасности.

Чтобы обезопасить инсталляцию Camunda, она должна быть правильно сконфигурирована и интегрирована в окружение. Этот раздел также идентифицирует области, для которых мы считаем проблемы с безопасностью релевантными для конкретных продуктов Camunda 7, которые мы перечислили в последующих разделах. Соответствие стандартам безопасности для этих областей обеспечивается на основе общих лучших практик индустрии и находится под влиянием требований к безопасности, таких как OWASP Top 10 и других.

Опции деплоймента и компоненты

Существуют различные способы использования Camunda 7 и различные компоненты: сам движок обработки процессов, REST API, веб приложения. В зависимости от того, как задеплоена Camunda и какие использованы компоненты, применяются различные соображения по безопасности. Приведенный ниже список дает базовую идею об опциях деплоймента и компонентах, очерчивая основные отличия с точки зрения безопасности. Остальная часть этой главы рассказывает в подробностях о различных опциях конфигурации.

  • Встроенная Java-библиотека внутри приложения: в этом случае движок Camunda встроен внутрь кастомизированного Java приложения. Обычно приложение заботится о том, чтобы обезопасить доступ к API, принадлежащих Camunda, и эти API не показываются конечному пользователю напрямую. В таком случае приложение обычно заботится об аутентификации и предотвращении доступа со стороны неавторизованных пользователей.

  • Разделенный движок управления процессами: при таком сценарии движок управления процессами деплоится как сервис контейнера в сервер приложений таким образом, чтобы он мог использоваться приложениями, задеплоенными в тот же контейнер / на тот же сервер. Этот случай похож на случай со встроенной Java библиотекой.

  • REST API: REST API предоставляет доступ к API ядра Camunda через HTTP. В этом случае пользователи могут напрямую получать доступ к API от Camunda. Обычно бывает необходимо конфигурировать аутентификацию, авторизацию и обезопашивать соединение с REST API, используя SSL (HTTPS).

  • Веб приложения (Cockpit, Tasklist, …​): применяются те же соображения, что и для случая REST API.

Не забывайте и о том, что не рекомендуется использовать предварительно упакованный дистрибутив в окружениях на продакшен. Лучше установить полный дистрибутив вручную (например, используя ручную инсталляцию Tomcat).

СООБРАЖЕНИЯ ПО БЕЗОПАСНОСТИ: Предварительно упакованный дистрибутив предназначен для пользователей, которые хотят получить начальный опыт. Если вы все же хотите использоваться его в продакшен, подумайте об удалении приложения "Invoice" и демо-пользователя.

Конфигурация безопасности внутри Camunda

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

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

Аутентификация контролирует, кто может получать доступ к API и приложениям Camunda.

Нужна ли мне аутентификация?

Аутентификация нужна только в следующих случаях:

  • Используется REST API от Camunda

  • Используются веб приложения от Camunda

В этих случаях предоставляется прямой доступ к API ядра Camunda поверх HTTP, но аутентификация должна быть включена.

По контрасту, аутентификация в Camunda обычно не осуществляется, когда она встраивается в приложение как библиотека. В этом случае приложение само заботится об аутентификации.

Включение аутентификации для REST API

Для простоты работы разработчиков, аутентификация в REST API отключена по умолчанию. Следовательно, при деплойменте REST API в продакшен необходимо подключить аутентификацию. Обратитесь к соответствующему разделу REST API документации.

Аутентификация в веб приложениях

Для веб приложений аутентификация включена по умолчанию, и отключить ее невозможно.

Кеш аутентификации

По причине наличия кеша аутентификации, по умолчанию следующие действия не оказывают немедленного эффекта на сессии пользователей, активные в текущий момент:

  • Удаление аккаунта пользователя.

  • Добавление или удаление членства арендатора/группы membership или авторизованного приложения на аккаунте пользователя.

Действия по управлению пользователями, упомянутые выше, могут позволить удаленному или неавторизованному пользователю продолжать считывать чувствительные данные или производить чувствительные для безопасности действия до истечения времени жизни кеша; по умолчанию, это максимум пять минут.

Чтобы предотвратить это, вы можете:

  • Установить время жизни в более низкое значение.

  • Полностью отключить кеш (установить его время жизни в 0), что приводит к запросам на информацию по аутентификации при каждом REST API запросе.

Заметьте, что изменение времени жизни на более низкое значение может повредить производительности вашего сервера базы данных.
Включение логирования аутентификации в Camunda web apps

Обычно рекомендуется включать логирование попыток логина (успешных или отвергнутых), так и события логаута. В Camunda вы можете включить логирование аутентификации в web apps, установив конфигурационный флаг webappsAuthenticationLoggingEnabled в движке управления процессами в true. Все инициированные пользователем события логина и логаута будут залогированы в логи приложения, используя логер io.openbpm.bpm.webapp.

Следующие события вызывают появление в логах новых вхождений:

  • Успешный логин с валидными креденшелами

  • Неуспешный логин с неправильным паролем

  • Неуспешный логин с недостаточной авторизацией

  • Неуспешный логин с несуществующим именем пользователя

  • Успешный логаут

Кто-то может использовать атаку типа brute force, производя произвольное количество вхождений лога и потенциально уменьшая дисковое пространство, доступное для хранения логов. Это может теоретически привести к DDoS, если логи хранятся на той же партиции, что и приложение. Camunda никак не предотвращает такие случаи, и ответственность за устранение подобного риска полностью лежит на разработчике, например, он может ограничить limiting количество попыток логина.

Управление пользователями изнутри (с помощью базы данных)

Чтобы выполнить аутентификацию, Camunda может использовать два источника: базу данных или LDAP.

При использовании базы данных имена пользователя и пароли хранятся в таблице ACT_ID_USER (см. документацию по схеме базы данных).Чтобы защитить пароли, сохраненные в базе данных, Camunda использует две концепции:

  • hashing: вместо хранения пароля в виде открытого текста сохраняется его хеш. При аутентификации генерируется такой же хеш из вводимой пользователем информации, после чего он сравнивается с хешем, хранимым в базе данных. Если оба хеша одинаковы, попытка логина оказывается успешной. Camunda позволяет конфигурировать и кастомизировать используемую функцию хеширования. См. раздел в документации о хешировании пароля, чтобы узнать об этом подробнее.

  • salted hashes: для защиты базы данных от атак типа rainbow table Camunda использует технологию salted hashes. Подобно обычному хешированию, эта функция может конфигурироваться и расширяться под нужды пользователя. См. раздел в документации о хешировании пароля , чтобы узнать об этом подробнее.

LDAP

В качестве альтернативы базе данных Camunda может использовать LDAP для проверки креденшелов пользователя при аутентификации. Camunda имеет read-only доступ к LDAP.

Авторизация

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

Надо ли мне включать авторизацию?

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

Ограничение доступа к данным через авторизацию

Авторизация может использоваться для предотвращения получения пользователем доступа к объекту данных (например, процессу или задаче) или для наложения ограничений на то, как именно пользователь может взаимодействовать с такими объектами данных (read-only или право на модификации). Авторизация в Camunda очень сильна, и мы рекомендуем прочитать соответствующий раздел в документации.

Предотвращаем: перечисление аккаунтов пользователей через brute-force атаку, создающую новых пользователей

В некоторых обстоятельствах атакующий может перечислять аккаунты пользователей, создавая новых пользователей через brute-force атаку:

Вы не управляете аккаунтами пользователей централизованно (например, с помощью LDAP или кастомизированной реализации WritableIdentityProvider), но вместо этого …​

  • …​ используете подход с "self-service" аккаунтом: неаутентифицированные пользователи могут создаваьт аккаунты; то есть? вы реализовали кастомизированный REST эндпоинт, который может создавать пользователей без аутентификации

  • …​ аутентифицированный пользователь имеет разрешение на действие CREATE для ресурса ANY USER, чтобы создавать новые аккаунты пользователей, и человек, не имеющий доверенного статуса, может получить доступ к такому аккаунту (см. документацию по сервису авторизации, чтобы узнать, как выдаются разрешения на ресурсы)

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

Мы настоятельно рекомендуе использовать продукт, где аккаунты управляются централизованно. Определенно не стоит управлять аккаунтами теми способами, которые перечислены выше.

Мы считаем, что вышеупомянутые сценарии нетипичны для организаций, использующих Camunda 7 Runtime. Однако, мы хотим проинформировать вас об имеющихся опциях, чтобы предотвратить нерекомендованное использование, которе делает продукт уязвимым для атак.

Предотвращаем: обход авторизация через повторное использование оставшихся пользовательских авторизаций

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

Мы создали такую схему авторизации, поскольку аккаунты пользователей обычно управляются централизованно внешним сервисом директория, таким как LDAP или кастомизированная реализация Java интерфейса ReadonlyIdentityProvider. Авторизация пользователя даже технически не может удаляться автоматически, поскольку внешний сервис директория не сообщает Camunda от том, что пользователь был удален.

ВНИМАНИЕ!: Даже если вы не управляете аккаунтами пользователей через внешний сервис директория, авторизации пользователей не удаляются автоматически.

Чтобы предотвратить это:

  1. Используйте группы вместо авторизации пользователя, когда это возможно.

  2. Завершайте задачи, назначенные на пользователя, который вот-вот должен быть удален.

  3. Удаляйте авторизации пользователей через приложение Admin или API.

  4. Не разрешайте переиспользовать id удаленного пользователя.

Spring Security OAuth2

См. документацию по рекомендациям по безопасности для интеграции со Spring Security OAuth2.

Деплойменты

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

  • BPMN, DMN, CMMN модели, которые выполняются движком на сервере Camunda

  • Скрипты и шаблоны ны различных языках (Javascript, Groovy, Freemarker, …​), на которые ссылаются BPMN, DMN, CMMN модели и которые движок выполняет на сервере Camunda

  • Выражения на Java EL, которые включаются в BPMN, DMN, CMMN модели ивыполняются на сервере Camunda

  • Формы, которые визуализирует в браузере пользователя клиентское приложение, например, Camunda Tasklist

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

Например, вы можете ограничить доступ к деплойментам следующими способами:

  • Используя авторизацию, администраторы дают разрешение на CREATE для ресурса Deployment только доверенным пользователям

  • Приложение, которое встраивает Camunda Java API, может выбрать опцию не показывать API для деплоймента на не пользующихся доверием каналах (например, для HTTP запросов)

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

Вы также можете прочитать раздел руководства пользователя по кастомизированному коду и безопасности, чтобы получить больше информации.

Ограничение количества попыток логина

Движок дает опцию ограничения количества (throttle) попыток логина. Обеспечивающий эту функцию механизм включен по умолчанию. Вы можете прочитать об этом больше в разделе "Сервис идентификации" в руководстве пользователя.

Кастомизированный белый список для ID пользователей, групп и арендаторов

Чтобы определить, допустим ли предоставленный ID, его можно сравнить с паттерном белого списка (Whitelist Pattern). Вы можете прочитать об этом в разделе "Сервис идентификации" в руководстве пользователя.

Политика паролей

При использовании управления идентификаторами, предоставленного самим движком (то есть, не LDAP), можно сконфигурировать политику паролей, чтобы гарантировать, что все пароли пользователей отвечают определенному стандарту безопасности.

Начиная с версии 7.11, может быть включена встроенная политика паролей, которая требует, чтобы пароли отвечали определенным правилам. Однако, вы можете достичь гораздо более высокого уровня безопасности, реализовав более продуинутую кастомизированную политику паролей (например, с помощью внемение паролей в черный список по торпологии, также см. гайд OWASP по сложности паролей).

Вы можете найти больше информации по подключению базовой политики паролей и по реализации кастомизированной политике паролей в нашем руководстве пользователя.

Формы

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

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

Запросы

Выражения в запросах

Подумайте об отключении выполнения выражений в запросах. См. также: Кастомизированный код и безопасность.

Нативные запросы

Одна из опций отправки запроса к данным из движка — это отправка нативных запросов. Что означает предоставление собственных SQL запросов для извлечения сущностей движка, если Query API не обладает нужными вам возможностями. Однако, используйте нативные запросы с осторожностью. Помните об SQL Injection, когда используете данный подход.

Предел на максимальные результаты в запросах

Использование REST API или отправку запросов к Webapps без ограничения на максимальное количество результатов или отправка запроса на большое число результатов может привести к высокому потреблению памяти или даже к исключениям типа out of memory.

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

ВНИМАНИЕ!: Чтобы пользоваться полным набором возможностей Webapps и не страдать от деградации, вызванной недоступностью данных, необходимо установить queryMaxResultsLimit в 2000. Воспользуйтесь руководством пользователя, чтобы узнать больше о пределе на максимальный результат запроса.

Предотвращение CSRF в Webapps

Фильтр CSRF включен по умолчанию и валидирует каждый запрос на модификацию, поданный через webapps. См. также детальный обзор конфигурирования предотвращения CSRF.

Предотвращение CSRF использует cookie. По умолчанию наличествует несколько конфигураций, относящихся к безопасности и работающих с этим cookie. Чтобы гарантировать полную безопасность, обратитесь к документации по безопасности Cookie, где вы сможете узнать больше по данному вопросу.

XML-безопасность

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

Если ограничения нв XML файлы, введенные для предотвращения XXE, должны быть сняты, можно разрешить обработку XXE через enableXxeProcessing в конфигурации движка управления процессами.

FSP как таковое отключить внутри движка нельзя. Все свойства, находящиеся под воздействием этого явления, могут, однако, конфигурироваться в окружении через свойства системы и в файле jaxp.properties. См. документацию Oracle по вопросу определения правильных ограничений и как их установить.

Поскольку валидация BPMN схемы требует внешних XSD documents, свойство http://javax.xml.XMLConstants/property/accessExternalSchema по умолчанию конфигурируется в значение all, что позволяет ссылаться на XML схемы через любой поддерживаемый протокол. Это можно переопределить через системное свойство javax.xml.accessExternalSchema, однако, значение, установленное через jaxp.properties, эффекта не возымеет.

Безопасность HTTP заголовка в Webapps

Из коробки веб приложения поддерживают следующие HTTP заголовки:

  • XSS Protection

  • Content Security Policy

  • Content-Type Options

  • Strict Transport Security (необходимо подключить в явном виде)

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

В зависомости от требований вашего проекта, некоторые из этих заголовков могут быть сконфигурированы более строго или более мягко. См. документацию по безопасности HTTP заголовка, чтобы узнать больше о нескольких заголовках, их значениях по умолчанию и как конфигурировать HTTP заголовки под ваши нужды.

Значения переменных из не заслуживающих доверия источников

Процессные переменные могут быть введены как Java-объекты, используя встроенный формат данных JDK application/x-java-serialized-object, JSON или XML вместе с именем Java-класса через Camunda REST API и веб приложения. На стороне сервера они могут быть десериализованы в Java-объекты, чтобы код на Java мог работать с ними нативным образом. См. Camunda Spin, чтобы узнать об этом более подробно, а также этот энопоинт REST API в качестве примера.

Если атакующий может получить доступ к этим эндпоинтам, он может воспользоваться так называемыми serialization gadgets, то есть классами, которые запускают уязвимый код во время демериализации, что в общем случае приводит к выполнению удаленного выполнения кода. Например, рассмотрим конструктор класса, который создает REST-запрос, основанный на значении поля. Атакующий сможет ввести сфабрикованное значение переменной таким образом, чтобы во время десериализации, когда вызывается конструктор, сервер приложения выполнил произвольный REST-запрос в направлении, соответствующем выбору атакующего. Чтобы узнать больше подробностей, см. описание десериализации не заслуживающих доверия данных от OWASP.

Java-объекты, использующие встроенный формат данных JDK application/x-java-serialized-object

Начиная с версии 7.9, по умолчанию не является возможным установить переменные типа Object И формат данных application/x-java-serialized-object. Это поведение может быть восстановлено через флаг конфигурации движка управления процессами javaSerializationFormatEnabled. Однако не забудьте, что разрешение на использование Java формата сериализации может сделать движок уязвимым к вышеупомянутому сценарию атаки.

Сериализованные объекты JSON/XML, использующие Spin

Поэтому мы рекомендуем включить добавление в белый список разрешенных Java классов через включение свойства deserializationTypeValidationEnabled в конфигурации движка управления процессами. Если это сделать, движок будет валидировать имена классов вводимых переменных через белый список разрешенных Java классов и имен пакетов. Любой не находящийся в белом списке контент отвергается. По умолчанию значения являются безопасными, но это может слишком сильно ограничивать ваш сценарий использования. Вы можете использовать свойства движка deserializationAllowedPackages и deserializationAllowedClasses, чтобы расширить белый список по умолчанию именами пакетов и классов Java-типов, которые вы считаете безопасными для десериализации в вашем окружении.

Если такое поведение нуждается в дальнейшей настройке, кастомизированный валидатор может быть реализован и зарегистрирован в движке через свойство движка deserializationTypeValidator. Предоставленный объект должен быть подтипом io.openbpm.bpm.engine.runtime.DeserializationTypeValidator и содержать реализацию метода #validate. В случае, если вы хотите также полагаться на имена разрешенных пакетов и классов из конфигурации движка, вы можете предоставить подтип io.openbpm.bpm.engine.runtime.WhitelistingDeserializationTypeValidator. Реализация этого интерфейса, зарегистрированная как валидатор, будет предоставлена с заданными пакетами и классами из конфигурации движка при инициализации движка через #setAllowedClasses и #setAllowedPackages.

Реализация JSON, используемая в Spin, основана на Jackson. Если вы конфигурируете Camunda Spin для десериализации полиморфных классов на основании информации, включенной в сам JSON itself (то есть там, где JSON содержит явные имена классов), мы настоятельно рекомендуем также включить возможность добавления в белый список от Jackson, начиная с версии 2.10. Добавление в белый список, как оно реализовано в Camunda, не покрывает этот случай.

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

Некоторые синхронные API могут использоваться для выполнения действий на нескольких сущностях, потенциально влияя на большие объемы данных.Для некоторых сценариев использования необходимо иметь лог этих операций для целей аудита.

Если не накладывать ограничений, двидок управления проуессами может потенциально создать неограниченное число вхождений в лог по пользовательским операциям. Лог пользовательских операций технически состоит из многих вхождений базы данных в таблице ACT_HI_OP_LOG. Количество вхождений в таблицу зависит от числа свойств, внесенных в лог пользовательских операций. Пример: синхронная корреляция сообщений может логировать до трех свойств (messageName, nrOfVariables, processInstance) в зависимости от некоторых условий. Операция синхронной корреляции сообщений на тысяче экземплярах процесса добавит 3000 новых строк в таблицу базы данных, содержащую лог.

Используя флаг конфигурации движка logEntriesPerSyncOperationLimit, можно ограничить количество создаваемых вхождений для лога пользовательских операций для синхронных вызовов API. По умолчанию на каждый вызов API в лог пользовательских операций вносится одно вхождение независимо от того, на сколько сущностей он повилял. (значение свойства по умолчанию равно 1). Если вы посчитаете нужным изменить logEntriesPerSyncOperationLimit, выбирайте значение,с которым сможет справиться ваша система, в чем вы полностью уверены. Чтобы узнать больше информации о возможных значениях для logEntriesPerSyncOperationLimit, посетите документацию по конфигурации.

В настоящее время это влияет на следующе APIs:

  • Message correlation

Конфигурирование безопасности во внешнем окружении

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

База данных

Camunda хранит свои данные в реляционных базах данных. Чтобы защитить доступ к этим данным, она должна быть правильно сконфигурирована. Эьтот раздел документации по The documentation section on поддерживаемым окружениям предоставляет список поддерживаемых баз данных.

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

Чтобы предотвратить доступ к данным, сохраненным в базе данных Camunda, вы должны следовать лучшим практикам при работе с базой данных, включая шифрование данных. Проконсультируйтесь с руководством по использованию, предоставленным вашим поставщиком.

Как обезопасить соединение с базой данных

Чтобы получить доступ к базе данных Camunda должна установить соединение. Обычно соединение конфигурируется либо напрямую через конфигурационные опции JDBC, либо через datasource, сконфигурированный внутри сервера приложений. Большинство драйверов баз данных поддерживают зашифрованные соединения и безопасность транспортных слоев при подключении к базе данных. При работе с Camunda и базой данных в сети, не являющейся доверенной рекомендуется включать эти возможности. Чтобы это сделать, ознакомьтесь с руководством по своей базе данных, драйверу к ней и по серверу приложений.

Как обезопасить креденшелы базы данных

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

Веб сервер (применимо при использовании REST API или веб приложений)

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

Разрешить SSL / HTTPS

Конфигурируем SSL / HTTPS при деплойменте Camunda REST API или веб приложений. Этого можно достичь через конфигурирование HTTPS либо на самом веб сервере, либо через обратный прокси. Подумайте об отключении HTTP и оставлении в конфигурации дл веб приложений только HTTPS. Прочитайте руководство по использованию вашего веб сервера или обратного прокси, чтобы узнать необходимые подробности.

Таймаут сессии

Установка таймаута сессии обычно производится через дескриптор деплоймента web.xml. Ознакомьтесь со спецификацией Java Servlet specification или руководством по использованию вашего сервера приложений.

Домен cookies

Домен для cookies сессии конфигурируется в специфической конфигурации для веб сервера. Если вы хотите установить такие cookies, ознакомьтесь с руководством по использованию вашего веб сервера, чтобы узнать подробности. Например, для Tomcat обратитесь к этому документу.

Максимальный размер POST на сервере (REST API)

Ограничение максимального размера в байтах в POST запросах специфично для вашего веб сервера. Ознакомьтесь с руководством по использованию вашего веб сервера, чтобы узнать подробности. Например, для Tomcat обратитесь к этой странице документации.

Как обезопасить cookies (веб приложения)

Контейнер предоставляет cookie для сессий. Обратитесь к документации по безопасности cookies, чтобы узнать, какие конфигурации необходимы для гарантии полной безопасности для cookie сессии.

Обработка ошибок

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

В этом разделе мы описываем, что мы делаем, чтобы предотвратить раскрытие технических деталей о системе.

Webapps

В Webapps, когда выдается ошибка, отображается страница ошибки общего назначения. Эта страница не включает никаких технических деталей, например, стэктрейсов.

REST API

REST API отображает только тип и короткое сообщение об ошибке, когда выбрасывается ошибка.

Предотвращение раскрытия внутреннего содержимого сервера приложений

В абзаце про обработку ошибок мы объясняем наши технические меры, направленные на предотвращение раскрытия технических деталей Camunda 7 Runtime.

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

Точная конфигурация и значения по умолчанию различаются от сервера к серверу.

Ниже приведен список документации о том, как правильно конфигурировать ваш сервер приложений:

Лицензия и атрибуция

Эта документация была создана на базе материала "Camunda 7 Docs" от Camunda, находится под лицензией Creative Commons Attribution-ShareAlike 3.0 Unported License .

Оригинал документации: https://docs.camunda.org