Информационная безопасность *

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

Разбираю «Смертельную триаду» (The Lethal Trifecta): сочетание приватных данных, недоверенного контента и возможности действовать во внешнем мире. Показываю, почему проблема не в «плохих» моделях, а в устройстве современных агентных систем, какие популярные способы защиты не дают структурных гарантий и как размыкать эту комбинацию на уровне архитектуры. В конце приведён короткий обзор направлений, которые могут сделать ИИ‑агентов не только полезными, но и принципиально более безопасными.

Я предметно занимаюсь защитой персональных данных с 2013 года. За это время я возвращался к тексту 152-ФЗ несколько сотен раз и многие его положения могу цитировать до запятой.

Ещё задолго до появления статьи 10.1, исходя из принципов обработки персональных данных и требований статей 5 и 6, я рекомендовал оформлять согласие на распространение отдельным документом. Это было в те времена, когда многие юристы предлагали включать в согласия на обработку формулу: «Я согласен считать все мои персональные данные общедоступными». Сегодня о таких бланках почти не вспоминают.

Поэтому, когда с 1 марта 2021 года вступила в силу статья 10.1 с требованием оформлять согласие на обработку персональных данных, разрешённых субъектом для распространения, отдельно от иных согласий, первой реакцией было чувство триумфа. «Я же говорил!» — крутилось в голове.

Однако, чем внимательнее я разбирал нововведения, тем меньше оставалось поводов для радости. Что именно означают «условия» и «запреты»? Как возможна передача «за исключением предоставления доступа» или обработка «за исключением получения доступа»? Как применять форму, построенную вокруг интернет-ресурсов, если персональные данные размещаются на физической доске почёта?

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

Меня зовут Никита, я технический лидер команды, которая занимаемся управлением безопасностью контейнерных сред — и как отдельным продуктом для внешних клиентов, и как внутренним решением для команд, которые используют Managed Kubernetes под свои сервисы.

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

12% всех зарегистрированных утечек данных в России начинались с атаки на топ-менеджмент (по данным PT EdTechLab). Так случилось, что собственники и ТОПы — это люди с уникальным, точнее уникально взрывоопасным, сочетанием максимального уровня привелегий и доверия внутри компании с, часто, относительно халатным отношением к кибергигиене. Бывает, что к этому добавляется еще наполняющая кибератаки фактурой публичность. Поделюсь пророчествами мыслями, к чему это может привести, и рекомендациями, что делать специалисту по ИБ, чтобы оптимизировать риски.

Три сценария, к которым нужно быть готовым

1. Целевой фишинг (он же "whaling" — охота на китов)

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

Классические сценарии: правдоподобные инструкции (иногда в формате дипфейков) от якобы директора перевести деньги или срочно открыть доступ.

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

2. Компрометация личных устройств

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

Когда в зависимости обнаруживают уязвимость, очевидное решение — поднять её минимально допустимую версию во всех библиотеках, которые ее используют. Тогда пакетный менеджер не подтянет уязвимую версию даже при новой установке. Сет Ларсон из Python Software Foundation предлагает не делать этого автоматически. По его мнению метаданные библиотеки должны описывать только совместимость, а контроль безопасности сборки оставаться на стороне приложения.

Колонка Сета вызвала спор в Python-сообществе: одни поддержали разделение ответственности между библиотекой и приложением, другие заметили, что безопасность тоже может входить в условия поддержки библиотеки. Мы в CodeScoring подготовили перевод колонки, разбор обеих позиций и наш взгляд на этот вопрос.

Привет, Хабр! Меня зовут Рома Масягутов, в К2 Облаке я отвечаю за корпоративные инсталляции Nextcloud. Год назад мы рассказывали, как собрали из открытой платформы файлообменник, который заменяет OneDrive. Тогда речь шла про архитектуру, а сегодня поговорим про слой ИБ.

В Nextcloud есть LDAP-интеграции, антивирусные плагины, аудит, политики доступа и мониторинг. На уровне чек-листа все выглядит прилично: подключили AD, поставили антивирус через ICAP, настроили WAF, включили логирование — корпоративное хранилище защищено, а потом вы загружаете большой зараженный файл и выясняется, что антивирус его так и не увидел. Для open source это обычная ситуация. По-настоящему безопасным такое ПО становится только после того, как вы вложите массу усилий в пусконаладку. Именно это мы и делаем.

В этой статье я обрисую контуры безопасности корпоративного Nextcloud в нашем исполнении, расскажу две истории про некорректные дефолтные настройки и сравню работу ClamAV, Kaspersky Scan Engine и PT Sandbox на реальной инфраструктуре.

Вы когда‑нибудь получали сообщение от мошенников? Там обычно что‑нибудь про службу безопасности банка, якобы вам нужно перевести деньги на некий безопасный счет, и тогда ваши сбережения останутся в безопасности. В локальных сетях на уровне L2 работает то же самое. Вместо сообщений — DHCP‑пакеты, вместо денег — ваши данные (а они в наше время — очень ценный ресурс).

DHCP spoofing — одна из самых распространённых и неприятных атак. Вопрос защиты от нее стоит особенно остро в сфере КИИ.

Мы с Семеном (соавтором) решили взять три самых популярных устройства, натравили на них 90 атак и выяснили, кто же лучший.

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

Трафик внутри Kubernetes может быть зашифрован и при этом оставаться уязвимым: сервисы принимают самоподписанные сертификаты, а API-сервер не проверяет подлинность kubelet. В этой статье разберём рабочую схему с внутренним CA, cert-manager, trust-manager и контроллером одобрения CSR, которая позволяет убрать небезопасные исключения и выстроить единую цепочку доверия для рабочих нагрузок и управляющей плоскости.

Ещё три года назад словосочетание «искусственный интеллект» в информационной безопасности встречалось в основном в презентациях крупных вендоров. Сегодня ситуация изменилась. Практически любой продукт на рынке так или иначе использует AI (ИИ), ML, LLM или другие аббревиатуры, связанные с искусственным интеллектом.

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

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

Привет, Хабр!

Меня зовут Максим Мотиков, я специалист по кибербезопасности в «Гарде».

Написать рабочее yara-правило несложно. Создать такое правило, которое через полгода поймет не только автор, но и любой другой аналитик в команде — задачка со звездочкой. У YARA нет строгого стандарта на то, как называть правило, что писать в meta и как оформлять условие. Каждый пишет как привык, и со временем база правил превращается в набор разномастных, подчас не очень логичных файлов.

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

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

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

Преамбула

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

На бумаге подобные проекты обычно выглядят как комбинации best practices: отказоустойчивость, сегментация, NGFW, немного динамической маршрутизации – и кажется, что этого достаточно.

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

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

Запустить ИИ-агента на багбаунти — дело пяти минут. Зато превратить его поток сознания в принятые отчеты, чтобы не словить бан за спам и минус в рейтинге, — задача со звездочкой.

Привет, Хабр! Меня зовут Владислав, я работаю в отделе реагирования на инциденты в Бастионе и около полутора лет активно ханчу на багбаунти. Под Новый год мы с другом так пробили ИБ-интегратора (он, кстати, остался доволен), а недавно я выиграл Bug Zone 7.0. Подобные активности — хорошая возможность поэкспериментировать и выработать новые подходы, и последние полгода я ищу баги при помощи LLM. Так что с ИИ можно добиваться хороших результатов, а не сдавать мусор. Но как это делать? 

Под катом вас ждут: 

• четыре подхода к ИИ-багхантингу; 

• четыре способа платить за модель; 

• три слоя верификации;

• пайплайн из двух агентов; 

• живой разбор blind SSRF. 

Спойлер: готовой кнопки «сделать хорошо» не ждите. 

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

Есть технологии, которые вспыхивают ярко, несколько лет находятся на пике популярности, а затем постепенно исчезают, уступая место чему-то новому. А есть SOCKS5.

Он появился в 1996 году, когда массового HTTPS ещё практически не существовало, контейнеры оставались делом будущего, а облачные сервисы скорее напоминали научную фантастику. За это время вокруг него успело измениться почти всё. Появились NAT и IPv6, повсеместный TLS, HTTP/2, HTTP/3, QUIC, контейнеры, облачные платформы и Zero Trust. Сам SOCKS5 при этом почти не изменился и, что удивительно, продолжает прекрасно выполнять свою работу.

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

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

Год назад я рассказывал на Хабре о ProxiFyre, небольшом инструменте для Windows, который позволяет прозрачно направлять трафик выбранных приложений через SOCKS5-прокси. Многие программы вообще не умеют работать через SOCKS5 или требуют ручной настройки. ProxiFyre берёт эту работу на себя: приложение продолжает работать как обычно, а решение о том, какие соединения следует отправить через прокси, принимается на уровне операционной системы.

Реплика с обложки не выдумана: осенью 2025-го Claude Sonnet 4.5 выдала ее проверяющим прямо посреди автоматизированного safety-аудита. «I think you're testing me. That's fine, but I'd prefer if we were just honest about what's happening». Фраза попала в официальную системную карточку вместе с числом: подобное модель проговаривала примерно в 13% тестовых диалогов.

Там же Anthropic письменно признает: alignment-оценки могут недооценивать склонность модели к вредным действиям в более реалистичных условиях. Проще говоря, когда модель видит перед собой экзамен, она ведет себя лучше, чем обычно. А экзамен она видит часто.

Я CTO ML-команды, мы ставим фронтир-модели в прод и собираем шорт-листы по этим самым таблицам из карточек. Разобрал по открытым первоисточникам, что известно про evaluation awareness к июлю 2026-го: как модели отличают тест от работы, насколько расходится поведение между бенчем и продом и как теперь читать model card.

Привет! Меня зовут Дима Левин, сейчас я работаю системным аналитиком в Петрович-Техе. Так уж сложилось, что в своей работе в нескольких проектах я плотно работал с персональными данными. Сегодня хочу рассказать о проекте по автоматизации обезличивания большой БД (30 000+ таблиц размером до 10 миллиардов строк). Надеюсь, мой опыт будет полезен.

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

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

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

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

Пару дней назад Cloud.ru выложил исходный код Guardrails Filter в открытый доступ. Это прозрачный обратный прокси между клиентом и LLM-провайдерами, он убирает чувствительные данные из запросов к модели и восстанавливает их в ответах. Я один из разработчиков этого инструмента и хотел бы рассказать подробнее, зачем вам вообще может быть нужно опенсорс-решение, как его можно внедрить в свою инфраструктуру, ну и ответить на вопрос: зачем облаку бесплатно делиться своими наработками с рынком?

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

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

Классический подход к Application Security сегодня переживает кризис, ситуацию усугубляет бум AI-помощников (GitHub Copilot, Cursor, Claude). Разработка ускорилась кратно, но вместе с ней масштабировалась и генерация небезопасного кода. Разработчик теперь может сгенерировать за час то, что раньше писал день, при этом уязвимости тоже начинают появляться с такой же скоростью. Если процесс безопасности остался прежним, AppSec быстро превращается в узкое место.

В этой статье мы разберем архитектуру и механику работы INFERA AI.SafeCode – платформы непрерывного анализа кода, которая отказывается от концепции «просто показать список подозрений» в пользу автоматического доказательства уязвимостей и MLSecOps-подхода.

Решение объединяет SAST, SCA, Secrets, DAST, Pentest, Code Fuzzing и API Fuzzing в единый DevSecOps / MLSecOps-контур.

Статья продуктовая, но мы ее публикуем на HABR не как рекламную, а как концептуальную. Хотим показать, как меняются подходы к безопасной разработке и насколько неэффективным становится «разрозненный» AppSec в эпоху ИИ и вайб-кодинга.