Пещера Алладина для безопасника: 754 навыка для AI-агента и что будет, если использовать их для своего NGFW

от автора

Разбираемся с открытой библиотекой Agent Skills для кибербезопасности на 754 навыка, показываем, как она устроена, и проводим живой эксперимент: даём агенту Hermes два навыка и просим разобрать реальный IPS-лог и провести аудит правил файрвола – сначала на бесплатной модели Owl Alpha (из-за того что подобную модель при желании можно использовать локально), затем на платной Opus 4.8 (Cloude Security). Сравниваем, где проходит граница между «бесплатно» и «дорого, но качественно».

Откуда взялась «пещера»

В одну ночь у нас на столе оказались четыре вещи: открытый репозиторий с 754 (!) навыками по ИБ для AI-агентов, автономный агент Hermes от Nous Research, LLM-модели Owl Alpha и Opus 4.8, а также открытое API Ideco NGFW в markdown-формате и соответствующий тестовый сервер.  Собрали всё вместе и проверили на что способен AI-native администратор NGFW.

Ощущение от первого захода в репозиторий было ровно как у Аладдина в пещере: вокруг сундуки с готовыми playbook’ами, на каждый второй случай из жизни безопасника. Volatility3 для дампов памяти, Zeek для разбора PCAP, Sigma-правила под Kerberoasting, разбор Cobalt Strike beacon, форензика облаков на трёх провайдерах. И ключ ко всему этому богатству – почти любая LLM, которая умеет в tool calling.

Проведем эксперимент: два конкретных навыка из сетевой безопасности, один агент, реальные данные. И в конце – где здесь грабли, на которые легко наступить.

Что такое Agent Skills и почему это не просто очередные промпты

Agent Skills – это открытый формат для расширения возможностей AI-агента специализированными знаниями и рабочими процессами. Вместо того чтобы каждый раз промтом объяснять модели, «как senior-аналитик расследует утечку через DNS-туннель», вы один раз описываете этот workflow в структурированном виде – и подкладываете агенту.

Технически навык – это директория с файлом SKILL.md. Внутри – YAML-фронтматтер для быстрого обнаружения и Markdown-тело с пошаговой инструкцией:

skills/performing-memory-forensics-with-volatility3/
├── SKILL.md              ← определение навыка (YAML + Markdown)
├── references/
│   ├── standards.md      ← маппинг на MITRE ATT&CK, ATLAS, D3FEND, NIST
│   └── workflows.md      ← глубокая техническая процедура
├── scripts/
│   └── process.py        ← рабочие вспомогательные скрипты
└── assets/
    └── template.md       ← шаблоны отчётов и чек-листы

Ключевая находка здесь – progressive disclosure. Сканирование фронтматтера одного навыка стоит агенту порядка 30 токенов, а полная загрузка тела – 500–2000 токенов. Это означает, что агент может за один проход просмотреть все 754 навыка, отобрать релевантные по тегам и описанию, и подгрузить в контекст только два-три нужных. Никакого раздувания контекстного окна.

Выглядит это примерно так, как описывает сам репозиторий:

Запрос: «Проанализируй дамп памяти на признаки кражи учётных данных»

Что делает агент:
  1. Сканирует 754 фронтматтера (~30 токенов каждый)
     → находит 12 релевантных навыков по тегам и описанию
  2. Загружает топ-3 совпадения:
     • performing-memory-forensics-with-volatility3
     • hunting-for-credential-dumping-lsass
     • analyzing-windows-event-logs-for-credential-access
  3. Выполняет workflow пошагово
     → запускает плагины Volatility3, проверяет паттерны доступа к LSASS
  4. Валидирует результат и мапит на ATT&CK T1003 (Credential Dumping)

Важная оговорка. В названии репозитория стоит слово «Anthropic», но это независимый community-проект, не аффилированный с компанией Anthropic PBC. Эта библиотека навыков – работа энтузиаста, а не известного вендора. Для нас это не минус: открытость как раз и означает, что любой может проверить, форкнуть и допилить под себя. Но как и к любому OpenSource, нужно подходить осторожно и не забывать о основах информационной безопасности. Рекомендуем использовать агентов в строго контролируемой среде.

Что внутри: 754 навыка, 26 доменов, 5 фреймворков

Масштаб библиотеки – её главный аргумент. На момент анализа это 754 навыка в 26 доменах ИБ. Распределение по ключевым направлениям:

Домен

Навыков

Что покрывает

Cloud Security

60

Харденинг AWS/Azure/GCP, CSPM, облачная форензика

Threat Hunting

55

Гипотезо-ориентированные охоты, LOTL-детект, поведенческая аналитика

Threat Intelligence

50

STIX/TAXII, MISP, интеграция фидов, профайлинг акторов

Web Application Security

42

OWASP Top 10, SQLi, XSS, SSRF, десериализация

Network Security

40

IDS/IPS, правила файрвола, сегментация VLAN, анализ трафика

Malware Analysis

39

Статический/динамический анализ, реверс, песочницы

Digital Forensics

37

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

Security Operations

36

SIEM-корреляция, анализ логов, триаж алертов

SOC Operations

33

Playbook’и, эскалации, метрики, tabletop-учения

OT/ICS Security

28

Modbus, DNP3, IEC 62443, защита SCADA

 

Отдельная сильная сторона – каждый навык размечен сразу под пять фреймворков: MITRE ATT&CK v19.1, NIST CSF 2.0, MITRE ATLAS, MITRE D3FEND и NIST AI RMF. Один навык – пять «галочек» по комплаенсу. Для тех, кто живёт в логике соответствия требованиям, это экономит часы ручного маппинга. Выглядит не сложно скорректировать навыки под требования ФСТЭК, КИИ и специфики российского регулирования.

Вот как это выглядит на одном навыке:

Навык

ATT&CK

NIST CSF

ATLAS

D3FEND

AI RMF

analyzing-network-traffic-of-malware

T1071

DE.CM

AML.T0047

D3-NTA

MEASURE-2.6

 

Тело навыка устроено стандартно: разделы When to Use (когда активировать), Prerequisites (что нужно), Workflow (пошаговое исполнение с конкретными командами) и Verification (как убедиться, что всё отработало). Это чек-лист – формализованный процесс принятия решений, по которому работает опытный аналитик.

Почему это вообще нужно: про дефицит кадров

Контекст, в котором всё это появилось, – хронический дефицит кадров в ИБ. К 2027 году дефицит кадров на рынке ИБ в России прогнозируется на уровне 54–65 тыс. специалистов (23–25% от потребности).

Сегодняшние модели умеют писать код и искать в вебе, но для ИБ им не хватает именно практических playbook’ов, превращающих генеративную LLM в способного аналитика. Джун знает, какой плагин Volatility3 запустить на подозрительном дампе и какие Sigma-правила ловят Kerberoasting. Базовая LLM этого не знает – пока вы не дадите ей навыки.

Это ровно та логика, которую мы в Ideco исповедуем в продукте: интеллект должен быть встроен в инструмент, а не жить отдельно в голове эксперта. Хорошо то, что интеллект сейчас подаётся агенту в виде переносимых текстовых навыков.

Эксперимент: Hermes + Owl Alpha администрируют реальный NGFW

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

Стенд

Компонент

Что использовали

Агент

Hermes Agent (Nous Research)

Модель

Owl Alpha – бесплатная фронтир-модель на OpenRouter, контекст 1,05M токенов

Навык 1

analyzing-network-traffic-for-incidents – для разбора IPS-лога

Навык 2

implementing-network-segmentation-with-firewall-zones – для анализа правил файрвола

Источник данных

Ideco NGFW API v22 (/ips/alerts, конфигурация правил)

Расход

~12 млн токенов на тестовые прогоны (112 запросов)

 

Пара слов про инструменты. Hermes Agent – это автономный агент с замкнутым циклом обучения: он создаёт навыки из опыта, улучшает их в процессе работы и строит модель пользователя между сессиями. Запускается где угодно – от локали и Docker до SSH и serverless. То, что нам и нужно: посадить его рядом со шлюзом и дать инструменты. Мы уже писали о его использовании для пентеста веб-приложений. В данных примерах используем его на MacMini.

Owl Alphaвысокопроизводительная foundation-модель под агентные нагрузки с нативной поддержкой tool use и длинного контекста. На момент эксперимента она бесплатна и числится в топе бесплатных моделей OpenRouter с расходом почти в 2 триллиона токенов. Используем ее для проверки, можно ли на для AI-Red/Blue-Team использовать локальные DeepSeek/Qwen модели.

Прогон 1: навык analyzing-network-traffic-for-incidents на IPS-логах

Навык заточен под разбор сетевого трафика и инцидентов: детект C2-биконинга, латерального движения, эксфильтрации. В оригинале он опирается на Wireshark, Zeek и NetFlow. Мы скормили агенту выгрузку IPS-алертов через API (4 353 события за сутки, 16 389 уникальных алертов в базе за месяц) и попросили отработать по шагам навыка.

Что нашёл агент – по убыванию серьёзности (данные обезличены):

CRITICAL – атаки изнутри сети. Агент сгруппировал события по источникам и подсветил несколько хостов:

Источник (обезличен)

Алертов

Что детектировано

Хост в подсети пользователей A

87 critical

Kolibri HTTP Buffer Overflow

Хост B

48

DNS Inverse Query Overflow (CVE-1999-0009)

Хост в WiFi-сегменте

262 (140 пропущено)

Imatix Xitami DoS

Хост C

30

User-Agent от Windows 98

 

Отдельно стоит история с попытками эксплуатации переполнения буфера в HTTP-сервере Kolibri – 87 критических попыток, 0 заблокировано, и все ночью, в 02:41–04:43. Источник – внутренний хост. Агент перечислил возможные сценарии: компрометация хоста (червь/бэкдор), легитимное сканирование уязвимостей (но ночью – подозрительно) или L2-спуфинг. И выставил приоритет P0: изолировать и проверить.

Отдельно стоит сказать, что явные false positive срабатывания сигнатуры «DNS Inverse Query Overflow (CVE-1999-0009)» агент на OWL Alpha никак не обозначал. Тогда как Cloude в подобных случаях и при перепрогоне выяснял ложность срабатывания и не добавлял их в отчет.

CRITICAL – IPS молчит 2+ часа. Последний алерт зафиксирован в 04:59:58, после чего – тишина. Агент сам предположил причины (краш Suricata, сбой event-syncer, переполнение базы логов, остановка сервиса администратором – последнее было верно для этого стенда) и поставил это первым пунктом плана: проверить работоспособность движка и настроить алертинг на саму остановку IPS. Это ценный момент: модель не просто разобрала то, что есть в логах, но и заметила отсутствие данных – а это классическая слепая зона автоматизированного анализа.

Любопытно, что срабатывание сигнатуры User-Agent от Windows 98 агент верно проинтерпретировал её двояко: либо это реально устаревшая ОС без обновлений безопасности 20+ лет (критический риск), либо спуфинг User-Agent для обхода фильтров. Оба сценария требуют расследования.

Заметим также, что человеку просмотреть 4,5 тысячи строк логов и выявить главное – заняло бы достаточное количество времени, даже с использованием фильтров.

Прогон 2: навык implementing-network-segmentation-with-firewall-zones на правилах файрвола

Второй навык – про правила файрвола и сегментацию: зоны, VLAN, ACL, микросегментация, принцип default deny. Агент по API самостоятельно получил доступ (в режиме «только для чтения») к конфигурации правил шлюза и провел аудит. Навык в оригинале ориентирован на Palo Alto / Fortinet / Cisco, но логика default-deny и анализа теневых правил универсальна – и агент применил её к нашей таблице правил. Благо Ideco NGFW имеет схожую структуру правил – zone-based firewall, профили IPS и контроля приложений в правилах.

Сводка находок (обезличено): 1 HIGH, 16 MEDIUM, 18 LOW.

HIGH – нет явного deny-all в цепочке INPUT. Последнее правило INPUT – автоматически созданное при миграции ANY→ANY ACCEPT без логирования. То есть весь трафик к самому NGFW разрешён по умолчанию: веб-интерфейс, SSH, API потенциально доступны из любой сети. Прямое нарушение принципа «запрещено всё, что явно не разрешено». Рекомендация агента: удалить auto-migration правило и добавить последним ANY→ANY DENY с логированием.

MEDIUM – дыры в аудите. Покрытие логированием оказалось неравномерным:

FORWARD:  ████████████████████░░░░░░░░  24/38 (63%)
INPUT:    ██████░░░░░░░░░░░░░░░░░░░░░░░   3/14 (21%)  ← критично
DNAT:     ██████████░░░░░░░░░░░░░░░░░░░   2/5  (40%)

Секция INPUT, которая управляет доступом к самому шлюзу, логируется всего на 21%. Агент обнаружил настройку глобального логирования правил log_mode=all, но ошибочно решил, что она не переопределяет настройку на уровне отдельного правила. Очевидно навык «из коробки» требует небольшой доработки. Причем сделать это может сам Hermes – достаточно сказать ему об этом и навык был адаптирован.

MEDIUM – теневые и дублирующие правила. Два catch-all ACCEPT подряд (один с DPI, другой без), причём второй полностью перекрывается первым. Правило блокировки порта 445 продублировано (TCP и UDP в разных правилах, одно никогда не срабатывает). Такой анализ – неоценимая польза на фарволах, содержащих сотни и тысячи правил (рекорд Ideco NGFW – 100 000 правил у одного из клиентов!).

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

Контрольный заход: те же задачи на Opus 4.8

После прогона на бесплатной Owl Alpha закономерно возник вопрос: а что изменится, если поставить вместо неё топовую платную модель? Мы повторили эксперимент на Claude Opus 4.8 – с тем же агентом, теми же навыками, но с двумя усложнениями. Во-первых, взяли свежее окно логов – 3 часа против суток у Alpha, но более нагруженный сервер: 21 500 событий безопасности. Во-вторых, добавили вторую стадию – расследование двух «подозрительных» хостов, которые модель сама же и подсветила на первой стадии. Цена вопроса вышла около 8 долларов. Данные, как и выше, обезличены.

Стадия 1: тот же навык анализа трафика, но плотнее

На окне в 3 часа (21 500 событий) Opus отработал тот же навык analyzing-network-traffic-for-incidents.

Что Opus сделал заметно лучше Alpha – это отделение сигнала от шума. Он сразу вычислил, что более половины всего объёма (около 11 700 событий, 54%) – это два «шумовых» класса: STUN Binding Response (легитимный WebRTC/VoIP-трафик) и AM INFO HTTP Cache-Control. И в рекомендациях предложил создать правила-исключения, потому что этот шум маскирует реальные инциденты. Alpha такой приоритизации «что выкинуть из поля зрения» не делал.

Дальше – две находки, которые Opus вытащил как приоритет P1 и которые в потоке из 21 500 событий легко пропустить вручную:

Находка (обезличено)

Сигнатура

Реакция IPS

Исходящее соединение к возможному C&C

Outbound connection to a possible C&C server (severity 1)

allowed (пропущено)

Загрузка PE-файла трояна

AM TROJAN Trojan/Win32.CeeInject (severity 2)

allowed + blocked (частично)

 

И положительная часть, которую модель отметила: блокировка хорошо работает там, где настроена – DoH-обход DNS-фильтрации (около 4 000 событий заблокировано), VPN и анонимайзеры (Browsec, HolaVPN, Anonymizer), фишинг-кит W3LL (частично).

Стадия 2: расследование хостов – то, чего Alpha не делал вовсе

Вот здесь проходит главный водораздел между моделями. Alpha остановился на «вот подозрительные хосты, проверьте их». Opus сделал следующий шаг сам: взял два IoC-хоста и провёл по каждому полноценное расследование, коррелируя пять разных источников – журнал IPS, журнал межсетевого экрана и DPI, журнал DNS с категориями угроз, активные сессии. Это уже не разбор одного лога, а мультиисточниковая реконструкция поведения хоста. Дай агенту еще данных – и он самостоятельно сделает корреляцию лучше SIEM.

Хост 1 – мнимый C&C, оказался ложным срабатыванием. Сигнатура severity-1 «исходящее соединение к C&C» выглядела угрожающе. Opus разобрал внешний адрес по PTR/AS – это оказался российский телеком-хостинг, соединение единичное, без бикон-паттерна и сопутствующих индикаторов. Проверил хост как источник и как назначение в IPS: только информационный шум и ложноположительные NOP-паттерны на трафике от CDN мессенджера. Сверил с DPI – трафик легитимный (DNS, QUIC/TLS к публичным облачным сервисам). Проверил DNS-угрозы: единственная «угроза» – домен сервиса автообновления Electron-приложений, ошибочно отнесённый к DNS-туннелированию, и тот уже блокируется фильтром. Вердикт: ложноположительное срабатывание, компрометации нет. На ручную отработку такой тревоги аналитик потратил бы час; Opus закрыл её с обоснованием за один проход.

Хост 2 – реальный детект, но с нюансами. Здесь модель не стала спешить с «всё чисто». Троян Trojan.Win32.CeeInject (сжатый PE) – это не ложное срабатывание, файл доставлялся через легитимный мессенджер по HTTP (порт 80), и антивирусный движок Ideco NGFW частично заблокировал передачу. Opus аккуратно развёл смягчающие факторы (доставка через легитимный канал, часть сессии заблокирована, нет последующей C2-активности и аномального exfil) и остаточный риск (часть файла из-за режима allowed могла достичь хоста). Итоговый вердикт – средний/высокий приоритет с конкретным планом: проверить эндпоинт на сохранение/запуск файла, опросить пользователя, рассмотреть блокировку передачи PE через мессенджеры в контентном фильтре. Ровно та работа, которую делает L2-аналитик SOC.

Alpha против Opus: где проходит граница

Оба прогона полезны, но они играют в разных лигах. Сведём наблюдения – с оговоркой, что окна логов и профили различались, поэтому сравнение качественное, а не лабораторно-чистое.

Критерий

Owl Alpha (бесплатно)

Opus 4.8 (~8$)

Базовый диагноз (IPS в режиме alert)

Нашёл

Нашёл и подтвердил с другого окна

Приоритизация шума (что игнорировать)

Слабо

Вычислил 54% шума, предложил правила-исключения

Разделение true/false positive

Не делал

Развёл FP и реальный детект по каждому хосту

Мультиисточниковая корреляция

Один лог (IPS)

Четыре источника (IPS, FW/DPI, DNS, сессии)

Глубина расследования хоста

«Проверьте этот хост»

Полный разбор с PTR/AS, вердиктом и планом

Ложные тревоги

Поднимал как критичные без проверки

Закрывал с обоснованием

Стоимость прогона

0 ₽

~8$

 

Ключевое отличие не в том, что Opus «умнее» в разборе одного лога – базовый системный пробел нашли обе модели. Отличие в глубине рассуждения и способности довести расследование до вердикта. Alpha работает как быстрый сканер, который поднимает флаги. Opus работает как аналитик, который эти флаги проверяет, отсеивает ложные и доводит реальные до плана действий. Для триажа потока алертов хватит и дешёвой модели; для расследования инцидента, где цена ошибки – ложная изоляция боевого хоста или, наоборот, пропущенная компрометация, разница в качестве оправдывает плату. Выглядит так, что здорово будет работать мультиагентная система, где AI-аналитик первого уровня будет проводить общий анализ, а фронтир-модель – глубокое исследование подозрительных хостов.

Очевидный и видимый вывод про сами навыки: один и тот же SKILL.md на сильной модели раскрывается существенно полнее. Навык задаёт каркас процесса, но насколько глубоко агент пройдёт по этому каркасу – зависит от модели.

Честный разбор: где здесь грабли

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

Грабля №1: данные ушли «наружу»

Главная и неустранимая в тестовом сетапе проблема. Owl Alpha – stels-модель на OpenRouter, и провайдер прямо предупреждает: промпты и ответы логируются и могут использоваться для обучения. Мы фактически отправили конфигурацию файрвола и IPS-логи тестового шлюза стороннему провайдеру. Для КИИ и во многих других случаях это не допустимо. Однако сопоставимую по качеству модель можно развернуть локально. Эксперимент доказал ее базовую эффективность.

С Opus картина не лучше «по факту отправки»: мы точно так же передали логи и конфигурации стороннему API. Разница лишь в условиях: у платных моделей обычно есть внятная политика по данным и режимы без обучения на ваших запросах, у бесплатной модели – прямое предупреждение о логировании. Но оба варианта – это вынос чувствительных данных за периметр.

Грабля №2: человек в контуре обязателен

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

Splunk в прогнозах на 2026 формулирует это как «гибридный человеко-агентный SOC»: агенты берут на себя повторяемую низкорисковую работу, а люди задают границы и проверяют решения. На русскоязычном Хабре уже выходил разбор Agentic SOC ровно в этой логике – самостоятельность агента должна быть ограничена четкими рамками.

Грабля №3: риск самих агентов как новой поверхности атаки

Когда мы даём агенту инструменты и право выполнять код, мы открываем новый вектор. OWASP Agentic Security Initiative относит неожиданное выполнение кода (RCE) агентом к угрозам наивысшего уровня: агент может быть склонён к генерации и запуску вредоносного кода в рантайме, минуя обычные процедуры авторизации изменений. Сюда же – prompt injection через те самые логи, которые агент анализирует. Если в логе есть строка, которую модель воспримет как инструкцию, поведение агента можно подменить.

Кроме того, нужно тщательно проверять навыки, которые вы используете – это тоже потенциальный способ перехвата контроля над агентом.

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

Что это значит для информационной безопасности

Открытая библиотека навыков снимает проблему «модель не знает, как работает настоящий ИБ-аналитик». Автономный агент даёт исполнительный контур. Дешёвый (или бесплатный) inference снимает порог входа. По отдельности всё это было и раньше – но именно сейчас три компонента сошлись настолько, что разбор боевого шлюза по навыку из открытого репозитория стал делом одного вечера и нуля рублей за модель.

Сравнение двух моделей добавляет важный нюанс к этой картине. Порог входа действительно нулевой: даже бесплатная модель находит системные пробелы. Но «потолок» расследования задаёт модель: переход от «вот флаг, проверьте» к «вот вердикт с обоснованием» – это ровно та работа, за которую платят аналитику SOC. Практический вывод – гибридная схема: дешёвая модель на первичном триаже потока алертов, сильная – на расследовании того, что прошло первичный фильтр.

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

Для нас в Ideco этот опыт ложится в собственную траекторию. Мы исходим из того, что безопасность должна не успевать устаревать – а значит, интеллектуальный анализ конфигураций, аудит правил и приоритизация инцидентов должны жить внутри продукта, под контролем, на ваших данных и без отправки логов неизвестным провайдерам. То, что в эксперименте мы делали внешним агентом на чужой модели, в правильной архитектуре должно работать локально, рядом с трафиком, с человеком в контуре и с полным аудитом действий самого агента. Открытый API Ideco NGFW v22, через который агент и забирал данные, – это как раз тот фундамент, на котором такие сценарии собираются без боли. Мы проверили, что раскрытия API достаточно и ничего не пришлось «объяснять» агенту дополнительно.

Что попробовать прямо сейчас

  • Установить агента (Hermes или OpenClaw);

  • Склонировать репозиторий навыков и просто почитать SKILL.md интересных навыков – это бесплатный конспект практик senior-аналитика.

  • Прогнать любой навык на обезличенном тестовом стенде, а не на боевом контуре.

  • Помнить, что агент с правами на инфраструктуру – сам по себе объект защиты.

А если вам интересно, как подобный анализ может работать внутри NGFW, на ваших данных и без отправки наружу – это ровно то направление, в котором мы движемся. Расскажем в следующих материалах.

ссылка на оригинал статьи https://habr.com/ru/articles/1043130/