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

NotCVE-2025-0003 и NotCVE-2025-0004

Продолжаю по мере сил пополнять базу проекта NotCVE информацией о проблемах безопасности, которым разработчики не желают присваивать CVE (делал заметку об этом проекте). В этот раз одна проблема в компиляторе Go привела к регистрации сразу 2-х записей:

• NotCVE-2025-0003

• NotCVE-2025-0004

Т.к. помимо самого компилятора Go, пострадал и Kubernetes:

The Go team has released a fix in Go versions 1.21.11 and 1.22.4 addressing a symlink race condition when using os.RemoveAll. The Kubernetes Security Response Committee received a report that this issue could be abused in Kubernetes to delete arbitrary directories on a Node with root permissions by a local non-root user with the same UID as the user in a Pod.

Из сообщения в гитхабе Kubernetes видно насколько заразительна тенденция вместо регистрации CVE называть фикс проблемы безопасности хардерингом:

The Go team has not issued a CVE for this, as it is considered a hardening issue, and the SRC is following that decision as well.

Собственно, в случае с Docker в этом году было то же самое, для них это тоже хардеринг (моё обращение в MITRE так и не привело к появлению CVE, поэтому я зарегистрировал NotCVE-2025-001).

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

В обсуждениях тестирования микросервисов часто всплывает статья Мартина Фаулера Testing Strategies in a Microservice Architecture. Опубликованная в 2014 году, она опирается на концепцию тестовой пирамиды, сформулированную ещё в 2009-м. С тех пор ландшафт тестирования заметно изменился — в первую очередь за счёт появления и широкого распространения Docker и Testcontainers, которые существенно повлияли на практики и экономику тестирования.

Эта трансформация хорошо отражена в более современных источниках:

• The testing pyramid is an outdated economic model

• Testing of Microservices (Spotify)

• Гарри Поттер и методы прагматичного программирования / Кирилл Мокевнин (Hexlet)

Сам Мартин Фаулер также в более поздней статье On the Diverse And Fantastical Shapes of Testing отмечает, что трактовка "юнит-тестов" далеко не однозначна и зависит от контекста.

В контексте вашего проекта это означает, что использование интеграционных тестов в 2025 году оказывается существенно проще, дешевле и эффективнее, чем это предполагалось в рамках модели 2009 года.

NotCVE-2025-0001

Прошёл месяц с момента моего обращения в MITRE про нежелание разработчиков  делать CVE из-за фикса в Docker Engine 28.0.0. От MITRE никаких новостей больше не было. Поэтому я обратился в NotCVE (об этом сервисе я делал заметку). Спустя буквально пару дней меня оповестили о создании идентификатора NotCVE-2025-0001.
Проект NotCVE пока ещё мало известен. По этой причине по запросу "NotCVE-2025-0001" пока далеко не во всех поисковиках что-то можно найти (в Гугл нашёл 1 запись, в Яндексе и DuckDuckGo - ничего). Да и идентификаторов в NotCVE пока всего лишь 6. Очень надеюсь, что проект обретёт популярность и количество идентификаторов увеличится. И в первую очередь - из-за повышения осведомлённости об этом проекте и увеличении обращений (из-за нежелания разработчиков признавать проблему и создавать CVE). В данном случае показательно, что идентификатор NotCVE-2025-0001 завели по моему обращению несмотря на то, что проблему нашёл не я. Я просто не смог пройти мимо, увидев нежелание разработчиков регистрировать CVE.

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

Шаг 1. Составьте карту сервисов и зависимостей

• Что включить: микросервисы, БД, очереди (Kafka, RabbitMQ), сторонние API (платежки, SMS).

• Зачем: чтобы понять, как падение одного компонента влияет на систему.

«Падение Redis "уронит" кэширование и увеличит нагрузку на БД».

Шаг 2. Разделите симптомы проблем: срочные vs важные

Срочные (реагировать немедленно!)

• БД: connections > 90%, replica lag > 10 сек.

• Платежный шлюз: 5xx errors > 1% за 5 мин, latency p99 > 3 сек.

• Kubernetes: pod restarts > 5/час, node CPU > 95%.

Инструменты: Grafana OnCall, PagerDuty.

Важные (требуют анализа)

• Рост ошибок 4xx > 5% за сутки.

• Увеличение времени ответа API на > 20% за неделю.

• Падение успешных сессий (Google Analytics).

Решение: алерты в Slack/Email.

Шаг 3. Автоматизируйте рутину

Сбор логов: стек EFK (Elastic + Fluentd + Kibana).

Kubernetes:

• Liveness-пробы → авто-перезапуск пода при сбое.

• Readiness-пробы → остановка трафика на проблемный под.

Redis: настройка политик очистки кэша.

Совет для ленивых:

«Используйте Coroot — он автоматически строит карту зависимостей и предлагает алерты»

Шаг 4. Тестируйте устойчивость

Chaos Engineering раз в месяц:

• Отключайте случайные ноды в кластере.

• Эмулируйте нагрузку в 10 раз выше обычной (Locust).

«Мониторинг должен не только сообщать о проблемах, но и подсказывать, что делать».

Шпаргалка о системном дизайне. Саму статью читаем тут: 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 оспорить (но, неудачно).

Приглашаю вас на весеннюю сессию вебинаров! Мы подготовили много экспертного контента и готовы поделиться с вами актуальной информацией о текущем состоянии и развитии рынка, а также современными подходами к защите веб-приложений и 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 Защита»

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