Микросервисы *

Шпаргалка о системном дизайне. Саму статью читаем тут: https://habr.com/ru/articles/915376/

ITFB Group совместно с BPMSoft приглашает на вебинар, посвященный теме организации правильной подготовки к выбору сложных ИТ-решений на примере CRM-платформы.

Вебинар будет полезен компаниям крупного бизнеса (включая Enterprise), планирующим внедрение с нуля или замену legacy-систем как в рамках импортозамещения, так и при смене самописных решений для широкого класса ИТ-систем, автоматизирующих различные бизнес-процессы (BPM, HRM, ATS, КЭДО, SRM, СЭД и др.)

Обсудим:

⏩ Как важно подготовиться к выбору сложных ИТ-решений для крупного бизнеса на примере выбора CRM-системы

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

⏩ Как методология предпроектного обследования (ППО) от ITFB Group помогает создать качественный RFP (запросы предложения)

⏩ Кейсы: ППО незначительно увеличивает сроки и бюджет, но сильно снижает риски

⏩ Как при помощи ППО и гибкого лицензирования вендора можно снизить ТСО в проекте CRM

⏩ Применение ППО для выбора других сложных ИТ-систем (BPM, СЭД, SRM, HRM, ATS, КЭДО)

Спикеры:
Николай Чекин — директор по развитию отношений с партнерами, ITFB Group
Максим Илюхин — директор по продажам, BPMSoft

Дата и время: 29 мая в 11:00

ЗАРЕГИСТРИРОВАТЬСЯ

3 ключевые метрики, которые спасут микросервисный проект

Современные системы — это сложные экосистемы, где каждая ошибка может стоить бизнесу денег и репутации. Рассказываем, какие метрики нельзя игнорировать, чтобы не пропустить критичные сбои.

Инфраструктурные метрики

Базовые показатели вроде CPU и RAM уже не спасают. Для микросервисов важнее:

Статус подов в Kubernetes:

• Количество рестартов.

• Фейлы readiness/liveness проб.

• Используйте метрику kube_pod_status_ready в Prometheus, чтобы находить «битые» поды.

Трассировка запросов: время выполнения каждого этапа через Jaeger.

Пример: Если поды перезапускаются чаще 5 раз в час — это сигнал к немедленной проверке.

Бизнес-метрики

Инфраструктура может быть идеальной, но если падает конверсия — бизнес теряет клиентов. Отслеживайте:

• Конверсию платежей (например, от корзины к оплате).

• Время обработки заказов.

Код для .NET-сервиса:

using App.Metrics;

public class PaymentService {
    private readonly IMetrics _metrics;
    public PaymentService(IMetrics metrics) => _metrics = metrics;
    
    public void ProcessPayment() {
        try {
            // Логика платежа...
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);
        } 
        catch {
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);
        }
    }
}

Эти метрики интегрируются в Grafana, чтобы вы видели, как каждая транзакция влияет на бизнес.

Пользовательский опыт

Даже 1 секунда задержки может увеличить отток пользователей на 7%. Контролируйте:

• Время отклика API (p95, p99).

• Частоту ошибок 5xx/4xx.

• Структурированные логи с контекстом:

{
  "timestamp": "2023-10-05T12:34:56Z",
  "level": "ERROR",
  "userId": "a1b2c3",
  "operation": "process_payment",
  "message": "Failed to charge card: insufficient funds"
}

Теги вроде userId помогают быстро найти все связанные с ошибкой события.

Почему классический мониторинг не работает для микросервисов и облаков? Переход к Observability

Современные системы давно перестали быть монолитами — теперь это сложные экосистемы из микросервисов, облачных сервисов и распределенных баз. Но если ваш мониторинг всё ещё фокусируется только на CPU и RAM, вы рискуете пропустить критические сбои.

Главные проблемы классического подхода:

1. Невидимые бизнес-сбои: Сервер «живой», но конверсия платежей падает.

2. Поиск иголки в стоге сена: При ошибке в цепочке из 10 микросервисов метрики инфраструктуры не укажут на источник проблемы.

3. Ручная настройка: Часы на алерты для каждого сервиса вместо автоматизации.

Решение — Observability:

Объедините метрики (Prometheus), логи (EFK) и трейсы (Jaeger), чтобы система сама «объясняла» свои сбои.

Пример кода

Отслеживание конверсии платежей в .NET-сервисе:

// Отслеживание конверсии платежей  
using App.Metrics;  
public class PaymentService  
{  
    private readonly IMetrics _metrics;  
    public PaymentService(IMetrics metrics) => _metrics = metrics;  

    public void ProcessPayment()  
    {  
        try  
        {  
            // Логика обработки платежа...  
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);  
        }  
        catch  
        {  
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);  
        }  
    }  
} 

Код автоматически фиксирует успешные и неудачные платежи. Эти метрики интегрируются в Grafana для анализа бизнес-показателей.

📖 Нужны подробности? Читайте статью на хабре: «Эффективная стратегия мониторинга: ключевые метрики для успешного наблюдения»

В феврале 2025 вышел релиз Docker Engine 28.0.0, устранивший проблемы безопасности:

Fix a security issue that was allowing remote hosts to connect directly to a container on its published ports. moby/moby#49325
Fix a security issue that was allowing neighbor hosts to connect to ports mapped on a loopback address. moby/moby#49325

В официальном блоге вышла статья с подробностями проблемы и возможными сценариями атак. Но, CVE заводить разработчики не захотели. Я не знаю какими принципами руководствовались разаботчики. По мне слова "Fix a security issue" тождественны созданию CVE. Я обратился в MITRE с описанием ситуации через эту форму (выбрал Request type - other). И получил такой ответ:

Thanks for the submission. We will treat this as a dispute/escalation request and reach out to Docker next. Hopefully that will spur them on to assign (it often does) but if not, we will take a look at assignment. 

Once we hear back we'll let you know if they changed their mind and decided to assign or what the next steps will be.

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

К сожалению, нежелание признавать CVE со стороны различных разработчиков случается периодически. В моей практике была ситуация, когда разработчик не просто не хотел заводить CVE, а ещё и желал, чтоб я сам отозвал CVE. После моего отказа пытался CVE оспорить (но, неудачно). Подробности - в статье "Как я зарегистрировал CVE и разозлил вендора"

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

Основные темы вебинаров:

• Защита веб-приложений (WAF)

• Защита интеграций между сервисами (API Security)

• Тренды развития рынка защиты веба

• Безопасная разработка

Для кого:

CISO

ИБ-специалисты

ИТ-специалисты

DevOps

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

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

 Ссылка на регистрацию 

До встречи!

Хочу поделиться итогами последней моей переписки с ребятами из OpenGroup по поводу особенностей применения стандарта Archimate 3.2 для описания микросервисной архитектуры с использованием Docker.

Как оказалось, паттерн, который был предложен 4 года назад с применением элементов Node для моделирования docker-контейнеров после выхода версии стандарта 3.2 стал неактуален - поскольку Node потерял большинство типов связей, которые были для него допустимыми по отношению к Artifact.
Спросите, почему этот вопрос встал только сейчас ? Потому что полностью стандарт 3.2 был поддержан в редакторе Archi относительно недавно... плюс как раз появилась необходимость в актуализации старых схем технологического слоя - и тут-то и выяснилось, что больше нельзя показать, что docker-контейнер (Node) реализуется посредством docker-образа (Artifact).

Резюмируя итоги обсуждения с коллегами из OpenGroup:

• рекомендуется использовать для моделирования докер-контейнеров элемент Системное ПО (System Software), для которого по прежнему доступно установление связи Реализации от докер-образа (Artifact)

• элемент Node остается как элемент для моделирования некоей условной совокупности программно-аппаратных средств (включая физические, "не-ИТ" объекты - т.е. станки и др) - цитирую Jean-Baptiste Sarrodie: "используем Node, чтобы показать что именно будет размещать или предоставлять сервисы, не обращая внимания на то как эта функция будет реализована (приложение, сервер, контейнер и т.д.)". Иначе говоря Node остается некоей логической структурой, объединяющей физические элементы (System Software, Device и др.).

• элемент Device рекомендуется применять для моделирования не только физических, но и виртуальных машин (до этого были варианты использовать для "виртуалок" элемент Node) - но возможно в новой версии Archimate что-то уточнится

P.S.: почти месяц назад, 25 января, вышла версия Archi 5.5 - за это время удалось пощупать, и могу сказать, что обновляться стоит.

Из ощутимых улучшений:

• возможность удалять на схеме элементы-контейнеры (стиль nested - когда элементы помещаются друг в друга) без удаления вложенных элементов (команда "Delete from view (keep children)" )

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

Коллеги, добрый день!

Наша линейка продуктов ПроAPI, основанная на собственной концепции к управлению и защите API, уже успела себя хорошо зарекомендовать. Однако задача ИБ-специалистов – постоянно быть на шаг впереди злоумышленников. Сегодня у нас есть идеи, как усилить безопасность и противостоять новым вызовам, мы хотели бы узнать ваше мнение относительно их.

По ссылке ниже мы предлагаем пройти небольшой опрос, который займет не более 10 минут.
https://t.me/wmx_xdrbot

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

Последний Go-митап в этом году: как Go меняет подходы к разработке и тестированию

Уже через несколько часов, в 19:00, начнется онлайн-трансляция финального в этом году Go-митапа, где разработчики и технические лидеры сообщества обсудят инструменты кодинга на Go. В мероприятии примут участие эксперты из YADRO, Wildberries, Weborama и Ви.Tech. Регистрируйтесь на онлайн-участие. 

Программа:

Приветственное слово: Руслан Барсуков, ведущий инженер по разработке ПО в YADRO, и Виталий Левченко, технический менеджер в Wildberries, расскажут о планах Go-сообщества в Нижнем Новгороде.

«Генерация стабов для тестирования микросервисов по gRPC»

Кирилл Шувалов, разработчик дивизиона Телеком в YADRO, покажет, как с помощью Protoc стандартизировать тесты, упрощая их написание и повышая читаемость.

«Стриминг данных из Snowflake в Couchbase»

Александр Ванюшкин, разработчик в Weborama, поделится опытом создания плагина для Redpanda/Connect для оперативной обработки данных.

«Сборка проектов на Go: от Make до Mise»

Даниил Подольский, эксперт по разработке ПО в YADRO и один из лидеров внутреннего Go-сообщества, расскажет о развитии инструментов сборки и выборе оптимальных решений.

«Почему мы пилим монолит без микросервисов»

Кирилл Кузин, старший golang-разработчик, Ви.Tech, объяснит, как команда поддерживает сложную архитектуру и избегает ошибок при распиле монолита.

Пришлем ссылку на онлайн-трансляцию после регистрации на сайте →

Кто и как создаёт архитектуру программного обеспечения, какими навыками должен обладать такой специалист и каковы его карьерные перспективы? Чему учиться и как развиваться мидлам и синьорам, чтобы начать работать с архитектурой?

Ответы на эти и другие вопросы дадут наши эксперты во время бесплатного вебинара «Карьерный маршрут: от мидла до архитектора ПО». 

Вы узнаете:

— как стать архитектором ПО;

— чего ждут работодатели;

— какие скилы будут полезны, даже если вы ещё не работали с архитектурой ПО;

— как себя чувствуют такие специалисты на рынке труда.

Спикеры ↓

Дмитрий Бардин
Ведущий разработчик в Кинопоиске

Артём Попов
Корпоративный архитектор, «Газпромбанк»

Иван Харкевич
Корпоративный архитектор, «Райффайзен Банк»

Ждём вас 29 ноября в 18:00 мск.

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

Некоторые контейнеры (docker, например) могут внутри себя использовать iptables. Это означает, что и port knocking можно реализовать прямо в контейнере. Популярные вопросы: зачем нужен port knocking и какой смысл делать его в контейнере? Port knocking может снизить обнаружение сервиса (вместо попыток бороться с последствиями, когда сервис уже обнаружен: брутфорс, эксплуатация уязвимости). В случаях, когда нельзя использовать ACL. Особенно актуально в условиях, когда компании не успевают оперативно устранять уязвимости. В контейнере эта мера может быть полезной как подстраховка: если firewall (на хостовой системе или роутере) внезапно ослабнут правила защиты. Также это поможет разгрузить правила firewall хостовой системы.
Безусловно, port knocking, как и любая технология, не является "серебряной пулей". И в общем смысле не является заменителем какой-то другой. Но, используя port knocking совместно с другими решениями, можно существенно повысить безопасность сервисов. Внедрение данной защиты также потенциально увеличит доступное время для устранения уязвимости (пока её не начнут пытаться эксплуатировать на защищаемом сервисе). Использование port knocking также приводит к уменьшению логов. А, значит, логи проще обрабатывать. Кроме того, эта мера поможет решить проблему безопасности: доступности портов контейнеров NotCVE-2025-0001 (если используется docker версии ниже 28).
О проблемах на практике при внедрении port knocking, вариантах решения самых частых проблем и нюансах использования в docker контейнерах рассказано в этой статье. Сам скрипт для использования port knocking в docker контейнере тут.

Всем привет!

Поговорим снова о микросервисах. Я уже писал, почему не стоит делать слишком мелкие микросервисы https://t.me/javaKotlinDevOps/305 (блог в телеге я стал вести сильно раньше, чем на Хабре)
Но встает закономерный вопрос - "сколько вешать в граммах", в смысле - а какого размера должны быть микросервисы?
Обозначим нижний и верхний предел, а для этого придется вспомнить DDD.

Для начала рассмотрим понятие ограниченного контекста (bounded context). Это связанный набор сущностей из реального мира, для наименования которых используется "единый язык" (ubiquitous language) - непротиворечивый набор терминов. Эти сущности описываются в аналитике, тест-кейсах и превращаются в классы в нашем сервисе и в таблицы в БД. Контекстом как правило занимается одна команда - так проще всего поддерживать "единый язык". И за микросервис тоже должна отвечать одна команда. Т.е. ограниченный контекст - это отличный кандидат на микросервис. Но при этом у одной команды может быть несколько микросервисов. И контекст может быть достаточно большим. Т.е. у нас есть верхняя граница микросервиса.

Теперь рассмотрим понятие агрегата - группу сущностей, имеющую уникальный идентификатор, изменение которой производится атомарно. Т.е. агрегат - граница транзакции в БД. А т.к. возможность делегировать управление транзакцией СУБД - это очень крутая штука, то разделять агрегат между разными БД не стоит. При этом один микросервис = одна БД. Поэтому агрегат - нижняя граница микросервиса.

Плюсы шаблона Saga для микросервисной архитектуры

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

Например, вы разработали систему для покупки билета на самолет. В нем три сервиса: оплата, уведомление, бронирование. Сервис успешно списал деньги, выслал уведомление о покупке, но возникла ошибка на этапе бронирования. Как откатить изменения, когда у нас три независимых сервиса? В монолитном приложении нас бы спасли транзакции ACID. А в случае с микросервисами — Saga. 

Принципы работы Saga:

1. Разбиение на шаги: Saga состоит из шагов (транзакций) в каждом микросервисе, таких как списание средств и бронирование.

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

3. Асинхронное выполнение: шаги могут выполняться асинхронно, а при ошибке запускаются компенсирующие транзакции.

Стратегии реализации:

• Оркестрация: один сервис или оркестратор управляет всем Saga, что упрощает реализацию, но создает единую точку отказа.

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

Читайте больше про веб-разработку в канале нашего руководителя отдела PHP Саши Шутая.

В Облаке Рег.ру запустили KaaS-решение

Мы расширили линейку IaaS-, PaaS- и SaaS‑решений и запустили новое — Kubernetes as a Service (KaaS). 

Сегодня 30 % заказчиков облачной платформы Рег.ру предпочитают разрабатывать клиентские приложения на базе микросервисной инфраструктуры с применением технологии оркестрации контейнеров Kubernetes. 

Kubernetes считается наиболее популярным и удобным инструментом для управления контейнерами, хотя его самостоятельное развертывание занимает в среднем от нескольких часов до нескольких дней. Услуга Kubernetes as a Service поможет сократить этот этап до 5–10 минут и снизить количество рутинных процессов при обслуживании ИТ-инфраструктуры. 

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

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

Всем привет! 

Меня зовут Дмитрий. В ИТ я сравнительно недавно, всего 25 лет, из которых последние 22 в банковском секторе (ЦБ, ВТБ, Банк ДОМ.РФ). И за это время я стал смотреть по-другому на многие привычные вещи. 

Вот недавно я подумал, что русская народная сказка про царевну-лягушку, это не только про неё. Вы помните: "... нелегко с Кощеем сладить: его смерть ☠️ на конце иглы, та игла в яйце 🥚, яйцо в утке 🦆, утка в зайце 🐇, тот заяц сидит в каменном сундуке 🗃️, а сундук стоит на высоком дубу 🌳, и тот дуб Кощей Бессмертный, как свой глаз, бережёт...". 
Будто бы это не и сказка вовсе, а лаконичное описание архитектуры развертывания. Словно «игла» это приложение 🤖, со встроенной killer-feature, при падении которой происходит необратимое последствие - смерть Кощея. Если перевести на бизнесовый - уход ключевого клиента.

А сколько такого в жизни! И Кощей был побеждён лишь потому, что с гео-распределённым решением заморачиваться не стал, или не смог. 🙈
То есть, в переводе на ИТ-шный, намек этой сказки может выглядеть так: хотите чтобы Ваши сервисы жили вечно - не поступайтесь вопросами надежности ИТ архитектуры. 🏛️

А раньше эта сказка мне казалась просто сказкой ... ☀️

Задача обеспечения безопасности REST API может быть менее очевидной, но важно помнить, что REST API используется везде, где пользователю сайта или приложения нужно предоставить данные с сервера.

Приглашаю на вебинар 30 мая в 12:00, посвященный превентивной защите REST API.

Ведущие вебинара — Вадим Шепелев, инженер по информационной безопасности Вебмониторэкс и Лев Палей, CISO Вебмониторэкс.

О чем расскажем на вебинаре:

• Польза от спецификации API и как её собрать на основании трафика

• Какие типы уязвимостей это позволит обнаружить

• Как уменьшить поверхность атаки при помощи «ПроAPI Защита»

Регистрируйтесь по ссылке.

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

Компания Вебмониторэкс приглашает на вебинар 30 мая в 12:00, посвященный превентивной защите REST API.

Ведущие вебинара — Вадим Шепелев, инженер по информационной безопасности Вебмониторэкс и Лев Палей, CISO Вебмониторэкс.

О чем расскажем на вебинаре:

• Польза от спецификации API и как её собрать на основании трафика

• Какие типы уязвимостей это позволит обнаружить

• Как уменьшить поверхность атаки при помощи «ПроAPI Защита»

Кому полезно:

• Специалистам, участвующим в разработке критичных для бизнеса веб-приложений

• Руководителям подразделений по информационной безопасности

• Специалистам Application Security

Почему полезно:

• Актуальная проблема защиты REST API обусловлена участившимися атаками на веб-ресурсы российских компаний

Регистрируйтесь по ссылке.

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

Компания Вебмониторэкс ответит на этот и другие вопросы на своем вебинаре 16 мая.
Теорию подкрепит практический кейс заказчика.

 О чем расскажем на вебинаре:

- На что обратить внимание при обеспечении безопасности API в современных условиях. - Изменения в инфраструктуре. Что дальше?
- Защита и управление API. Почему это важно.
- Подходы по защите API. От зрелости к эффективности: Знать. Защищать. Не допускать. - Реализация на платформе «Вебмониторэкс»: компоненты для защиты и управления API.  

Ведущий вебинара — Лев Палей, CISO Вебмониторэкс. Специальный гость — Кирилл Ильин, CISO «СберАвто». Он честно и открыто расскажет о задачах, практике и результатах защиты API в своей компании.  

Кому полезно:

- Специалистам, участвующим в разработке критичных для бизнеса веб-приложений
- Руководителям подразделений по информационной безопасности
- Специалистам Application Security  

Почему полезно:

- Узнаете о современной концепции управления API
- Увидите пример ее реализации на платформе «Вебмониторэкс»
- Услышите от CISO об успешном опыте защиты и управления API на примере компании «СберАвто»  

Регистрируйтесь по ссылке.

Вебинар про защиту API 16 мая в 12:00

Monolith-first подход

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

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

В такой ситуации вы начнёте спокойно делить монолит на микросервисы. Выделите связанные контексты, начнёте вынос кода и миграцию баз данных. Это стандартная история IT-мира. У нас был монолит, но мы выросли и мигрировали на микросервисы.

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

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

Больше интересного про жизнь в IT у меня в ТГ

Вебмониторэкс приглашает вас 17 апреля в 12:00 (мск) на вебинар, во время которого мы раскроем тему значимости обеспечения безопасности API в современных условиях.

Ведущие вебинара - Лев Палей, CISO и Сергей Одинцов, системный аналитик Вебмониторэкс.

Расскажем об изменении ландшафта угроз и отражении этих изменений в OWASP API Security.
Подробно рассмотрим обеспечение безопасности веб-приложений в наиболее атакуемых отраслях (телекоммуникационные компании и интернет платформы).
Покажем, как платформа «Вебмониторэкс» решает задачи по защите веб-приложений и API.

Почему полезно:
  - Узнаете о новых уязвимостях в OWASP API Security и вариантах их эксплуатации
  - Получите рекомендации по защите своих API
  - Увидите примеры, иллюстрирующие изменения OWASP API Security

Продолжительность вебинара 1 час 30 минут!
Регистрируйтесь на вебинар по ссылке.