В этой роли предстоит регулярно проверять защищённость внешнего периметра и веб-приложений: искать уязвимости, исследовать возможные векторы атак и проверять их эксплуатацию на практике.
Чем предстоит заниматься
проводить разведку и сканирование внешнего периметра;
исследовать и эксплуатировать уязвимости сервисов;
проводить анализ защищенности веб-приложений (черный / серый ящик);
выявлять и проверять уязвимости;
готовить отчёты: описывать вектор атаки, оценивать критичность по CVSS и давать рекомендации по устранению.
Что нам важно
от 2 лет опыта в тестировании внешнего периметра и анализе защищённости веб-приложений;
опыт выявления и эксплуатации основных классов веб-уязвимостей: инъекции (SQL, Command, SSTI), XSS, SSRF, IDOR/BOLA, XXE, BAC, Insecure Deserialization, LFI/RFI, а также логических уязвимостей (Race Conditions, ошибки в бизнес-логике и др.);
уверенное владение Burp Suite/ZAP, ffuf/dirsearch, Nuclei, Amass/Subfinder, Nmap, sqlmap и другими инструментариями;
понимание работы современных веб-фреймворков: чтение кода на Java, PHP, JavaScript, Python;
Что предлагаем
официальное трудоустройство;
помощь в адаптации и погружении в задачи;
ДМС после испытательного срока, включая стоматологию, телемедицину, психологическую поддержку и ежегодное медицинское обследование;
страхование от несчастных случаев и при выезде за рубеж;
профессиональное развитие: курсы, тренинги и доступ к онлайн-библиотеке;
частичную компенсацию занятий спортом;
сообщество единомышленников по увлечениям и интересам (книги, спорт, фильмы и различные хобби);
Сигнатуры уже не панацея. Что происходит с WAF в эпоху умных ботов
Классический WAF хорошо справляется с угрозами, которые можно распознать по известным признакам, но сегодня трафик становится сложнее: боты имитируют поведение пользователей, проходят браузерные проверки, а приложения и API меняются быстрее, чем успевают обновляться политики безопасности. Поэтому к классическому WAF добавляются Bot Management, API Security и Anti-DDoS L7. В результате вместо набора разрозненных инструментов получается единый стек защиты, именуемый WAAP.
Мы уже писали о том, как WAF дополняется другими механизмами защиты,о важности связки WAF и Anti-DDoS ио том, как боты меняют структуру интернет-трафика. Но на деле вопросов у бизнеса с каждым днем всё больше и больше, поэтому мы собрали экспертов, которые смотрят на защиту веб-приложений с разных сторон: от клиентских решений и архитектуры ИБ до технического внедрения WAF. На вебинаре «WAFгуст 2026: от сигнатур к интеллекту» встретились:
Антон Апряткин, руководитель отдела клиентских решений, NGENIX;
Павел Кузнецов, WAF TechLead, Инфосистемы Джет;
Игорь Мишин, архитектор по информационной безопасности, ГК «РТК-ЦОД»;
Алексей Пашков, руководитель направления WAF, ГК «Солар».
Модератором встречи выступил Лука Сафонов, бизнес-партнер по инновационному развитию компании «Гарда».
Бот стал не похож на бота
Бот может не превышать rate limit, проходить JS Challenge через браузер и оставлять JA3/JA4-отпечаток, похожий на отпечаток обычного пользователя.
«Интернет практически полностью состоит из ботов, а интенсивность трафика меняется в зависимости от того, в каком регионе активнее используется конкретная модель», — отметил Лука Сафонов, бизнес-партнер по инновационному развитию компании «Гарда».
Как в такой ситуации понять, кто перед тобой: человек или автоматизированный запрос?
Неправильная настройка WAF может превратить защиту в слишком дорогую игрушку
WAF может заблокировать обычного пользователя из-за спецсимволов в пароле. Но если просто отключить правило для всей страницы, можно открыть путь вредоносному запросу. И это только один из сценариев, когда защита начинает конфликтовать с бизнес-логикой приложения.
Где проходит граница между безопасным исключением и дырой в защите? И сколько может стоить ошибка, если она случится в самый неподходящий момент?
Что считать результатом работы WAF?
Количество заблокированных атак — далеко не единственная метрика, которая интересует бизнес. Простои, нежелательный трафик, нагрузка на инфраструктуру, обращения в поддержку, конверсия — всё это тоже может быть связано с работой защиты.
Но какие показатели действительно имеет смысл выносить на уровень бизнеса? И как связать работу WAF с тем, что бизнес способен измерить в деньгах и операционных результатах?
Это лишь малая часть вопросов, которые обсудили на вебинаре «WAFгуст 2026: от сигнатур к интеллекту». Если хочется понять, как на эти вопросы отвечают практики и где на самом деле проходят границы современной защиты веб-приложений, — заглядывайте к нам на огонек.
Можно ли настроить MFA за 15 минут? Узнайте на вебинаре Avanpost 17 сентября
Можно ли усилить защиту удаленного доступа сотрудников всего за 15 минут? Эксперты Avanpost утверждают, что да, — и готовы доказать это в прямом эфире.
Avanpost начинает серию вебинаров о простой и быстрой организации Identity Security.
В первом выпуске:
✔️ эксперты расскажут об эталонной архитектуре Avanpost Identity Cloud,
✔️ докажут, что путь к Zero Trust из облака проще, чем кажется
✔️ и главное — покажут, как всего за 15 минут защитить подключение к удаленному рабочему месту сотрудника.
17 сентября в 11:00 мск ведущие запустят таймер и с нуля настроят MFA с помощью Avanpost Identity Cloud. А вы сможете наблюдать за всем процессом.
За эти 15 минут они:
✅ Развернут новый экземпляр Avanpost MFA+ в облаке;
✅ Настроят политику многофакторной аутентификации;
✅ Привяжут Avanpost Authenticator через QR-код;
✅ Включат многофакторную аутентификацию для OpenVPN;
✅ Выполнят вход с подтверждением на смартфоне.
😊Выглядит непросто? Тем интереснее проверить.
Присоединяйтесь и смотрите эфир до конца — участников ждет уникальное предложение от Avanpost, с которым защитить доступ сотрудников можно не только быстро, но и выгодно.
Ребят, возможно пригодится тем кто пользуется trusttunnel vpn на компе. Надоело перебирать bat'ники подумал, сейчас с клодом на питоне можно что угодно сделать. Cобрал небольшую программку, она запускается из любой директории (с правами админа, иначе vpn не подключится). В папке необходимы файлы самого сервиса trasttunnel и конфиги (в инфо есть как их надо обозвать). Удобно что видно когда впн подключился, проверяет сразу ваше местоположение и ip. Есть переключение на англ язык. Возможность менять сервера. Виден лог подключения. Сделал для себя, но решил поделиться. Выложил по совету товарищей на github - https://github.com/mobitop/trusttunnel Хотя по мне - просто хотел поделиться. Могу залить исходный код, только не знаю как :) Всем добра!
Треть объема файловых хранилищ российских компаний занимает цифровой мусор. И это только «цветочки»
Цифровой беспорядок ничем не отличается от обычного: пока не начинаешь разбирать, кажется, что всё под контролем. А потом открываешь папку с файлами или галерею телефона — и обнаруживаешь кэш, который давно пора очистить, копии ненужных документов и файлы, о которых уже успел забыть.
В корпоративных ИТ-инфраструктурах и масштаб больше, и последствия серьезнее. И проблема далеко не в том, что в хранилищах годами лежат ненужные файлы. Хуже всего, что среди этого разрозненного массива данных практически неизбежно оказываются файлы, содержащие конфиденциальную информацию. Если не автоматизировать процесс контроля и аудита, это повлечет за собой финансовые и репутационные риски.
За 2025 год мы проаудировали ИТ-инфраструктуру более сотни компаний — от финансового сектора до фармацевтики, проверили свыше 157 ТБ данных и более 511 тыс. учетных записей.
Делимся некоторыми фактами.
Итоги аудита
В среднем около трети объема файловых хранилищ занимает цифровой мусор: устаревшие файлы, которые не открывали несколько лет, копии и дубликаты документов, а также данные, не связанные с рабочими задачами. Например, личные фото, видео и случайные архивы сотрудников.
Проблема эта далеко не новая и сохраняется из года в год. Бороться с ней вручную практически невозможно: объем данных растет, а вместе с ним в геометрической прогрессии увеличивается и количество информации, за которой необходимо следить. Без инструментов класса DCAP здесь не обойтись.
С доступами ситуация тоже далека от идеала. Более 33% учетных записей имеют слабые пароли либо пароли, которые не обновлялись более 90 дней. В случае инсайдерской атаки такие учетные записи могут упростить злоумышленникам доступ к корпоративным данным. Поэтому компаниям важно разработать надежную парольную политику и автоматизировать ее соблюдение.
Еще один риск связан с правами доступа к сетевым хранилищам. На практике учетные записи сотрудников нередко создаются с одинаковым набором прав, а доступ к файловым ресурсам по умолчанию предоставляется всем. В результате в таком хранилище может оказаться конфиденциальная информация, доступ к которой могут получить злоумышленники.
Что осталось за кадром
Это лишь несколько фактов, которые мы регулярно подтверждаем в ходе аудитов. В полной версии отчета вы найдете больше цифр, разбивку данных исследования по отраслям и размеру компаний, а также рекомендации, как навести порядок в работе с данными и доступами, чтобы эффективнее управлять их жизненным циклом.
Появилось желание написать пост и выразить свое мнение касаемо вирусов на 2026 год.
Честно говоря, начать хочется с искренних соболезнований парням и девчонкам, которые каждый день приходят на работу и занимаются одной и той же унылой вещью - открывают новые сэмплы вредоносов, часами ковыряют их, анализируют и закидывают очередную строчку в базу сигнатур. Но это ладно, это заработок - и за это платят.
У менее опытных возникает вопрос, почему их анализ это невероятная скука? Я наверное начну пожалуй с того, что авторы вирусов перестали развиваться. Буквально. Используются ровно те же самые однотипные техники, которые вовсю гоняли еще лет десять назад. Собственно теперь представьте, что вам предстоит каждый день приходить в офис, дизассемблировать сэмпл и смотреть на одинаковые паттерны и техники, потом вносить сигнатуры базу, невероятная скука... не так ли? Кошмар какой-то. Единственное, в чем создатели малвари хоть как-то сдвинулись с места - они просто забили и перестали так назойливо пытаться спрятать свои функции.
Раньше была хоть какая-то интрига с обфускацией и хитровывернутыми протекторами, а сейчас многие понимают - современные системы кибербеза и SIEM-решения давно ушли в сторону анализа на основе корреляции событий. Зачем тратить недели на скрытие кода, если система безопасности всё равно спалит тебя по поведению, по подозрительной сетевой активности или по аномальным цепочкам вызовов? Многие это поняли.
Кстати, интересно то, что, создатели малвари до сих пор массово юзают чужие готовые крипторы, хотя смысла в этом с каждым годом всё меньше. Зато в моду вошла до смешного простая техника - они начали просто засорять таблицу импорта. То есть берут и пачками закидывают в код вызовы совершенно левых, безобидных системных функций, которые вирусу вообще не нужны. Я думаю многим не трудно понять, после какого‑этапа развития антивирусных систем это стало модно:) Выше был намек…
В целом. Сейчас вся наша IT-индустрия дико переоценена в плане романтики и каких-то высоких смыслов. Из каждого утюга, из каждой ИТ-школы кричат про горящие глаза, работу как хобби, бесконечное творчество и вечный кайф от технологий. Но если снять розовые очки, процентов 90 реальных задач в любой сфере - от веб-разработки до ИБ рано или поздно превращаются в обычный конвейер. И тут вообще не важно, трижды ты гений программирования или какой-нибудь крутой архитектор с кучей сертификатов. Рано или поздно ты неизбежно упираешься в ментальный потолок. Новые задачи щелкаются на автомате за полчаса, а внутри не зажигается абсолютно ничего. Наступает тупое, серое равнодушие.
Ты вроде бы работаешь в самой передовой индустрии планеты, вокруг ИИ, квантовые технологии и разговоры про сингулярность, а человек сидит и ковыряет сотый за месяц троян, собранный из фикалии и палок. И в этот момент важно вовремя поймать себя на мысли, что стабильный высокий оклад перестал окупать тупое онемение мозга)
Как по мне, единственный нормальный способ не сойти с ума, когда тебя начинает тошнить от вида собственного монитора - это иметь наглую смелость слать лесом все эти дурацкие правила про обязательный фокус на одном стеке. Хватит всю жизнь копать одну траншею. Надо просто брать и прыгать в полную неизвестность, лезть в кардинально другие направления. Просто ради того , чтобы снова почувствовать себя тупым новичком, который вообще ничего не понимает. Чтобы при виде сложной, незнакомой задачи у человека снова бешено врубался мозг, а от первой за неделю победы выделялся забытый дофамин. К тому же, это реальный шанс стать крутым специалистом на стыке нескольких разных областей. На этом все… Ваше мнение?
Пару недель назад прошла CTF от компании Касперский. Задачи, как вы понимаете, были из области классического ИБ: криптография (crypto), реверс инжиниринг (reverse), расследование инцидентов (forensics), внешний (web) и внутренний пентесты (misc), а также pwn (даже не знаю как правильно перевести).
И все бы ничего, но задачи были несравнимо "необычные", не чета таскам в до-ИИшную эпоху. Даже мою любимую форензику я не смог решить... ни одного задания. Давно у меня не было такого гнетущего ощущения как "эффекта самозванца". Но в чем оказался секрет?
Примерно через 20 минут после начала мероприятия наш сокомандник говорит: "Я решил первое задание!" На завидный вопрос коллег, а что там было и как решал, прозвучал ответ: "Я не знаю, я просто закинул архив и задание в ИИ и тот мне сам все решил". Прикольно, но как-то не спортивно мне кажется. Ладно, победителей не судят, а в правилах не было запрета на потусторонние силы.
Через 30 минут тоже самое повторилось и со вторым заданием, потом с третьим и так далее. В итоге, таким образом наша команда (читай ИИ) смогли решить чуть меньше 10 упражнений. В ходе последующих обсуждений мы все пришли к выводу, что CTF в целом уже не то, и сейчас мероприятия превратились в "борьбу кошельков", то есть у кого больше закуплено агентов. Вместе с тем и организаторы не стоят на месте и свои задания (судя по врайтапам) тоже генерируют через ИИ, потому что решить их руками в установленные сроки просто не реально. В общем, есть на чем задуматься.
К слову сказать, если сейчас перейти на сайт портала, чтобы посмотреть таски, то у вас ничего не получится: вас встретит заглушка об окончании мероприятия. НО! перед заглушкой на долю секунды мелькают задания... что намекает на скрипт, который проверяет текущую дату и сверяет с датами проведения CTF. Поэтому, если есть желание попробовать самому, то открываем Burp и ставим Intercept On. А если будет тяжело, можно посмотреть решения одного из участников - https://github.com/hax1ng/Kaspersky-CTF-2026/
🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
Хакерская группировка PhantomCore продолжает активно использовать ошибки в конфигурации 1С для атак на российские организации.
В рамках расследования инцидента команда комплексного реагирования на киберугрозы Positive Technologies (PT ESC IR) обнаружила компрометацию сервера 1С, работающего на операционной системе семейства Linux 🐧
Среди характерных признаков — наличие вредоносных исполняемых файлов в подкаталогах домашней директории служебного пользователя usr1cv8 и команд в .bash_history того же пользователя — в частности просмотр и удаление файла res.txt, в который записывается результат выполнения кода посредством 1cshell.
После получения доступа в систему PhantomCore установили ReverseSSH-туннель, что является типичным поведением для данной группировки.
🕵️♂️ Помимо часто используемого инструментария мы встретили и более диковинную утилиту croc, предназначенную для удаленной загрузки и эксфильтрации файлов.
На исследуемом узле были обнаружены команды формата: CROC_SECRET=[REDACTED] ./croc
С помощью нее злоумышленники могли загрузить на скомпрометированный узел файл, который был предварительно отправлен через веб-интерфейс https://getcroc.com/ (на скриншоте) или с другого компьютера, на котором установлен croc.
💡 Для поиска следов использования croc можно поискать исполняемый файл с соответствующим именем, а также использование переменной окружения CROC_SECRET.
В качестве сетевого индикатора может служить домен getcroc[.]com.
Как перестать сливать ПДн в ChatGPT и Claude: On-Prem AI-Gateway на чистом Python
Сотрудники компании (разработчики, поддержка, юристы) активно используют ChatGPT, Claude и Cursor. В промпты летят ФИО клиентов, ИИН/ИНН, карты, API-ключи и бизнес-логика. С точки зрения RegTech (152-ФЗ, Закон РК № 94-V, GDPR) — это прямая утечка данных.
Обычный DLP просто заблокирует доступ, снижая продуктивность[cite: 1]. Мы сделали AI-Gateway — open-source шлюз с обратимой токенизацией (Reversible Tokenization), который маскирует ПДн до отправки в LLM, восстанавливает их в ответе и ведет защищенный лог.
Как это работает
1. Исходный промпт от пользователя/приложения:
«Клиент Ержан Нурсултанулы, ИИН 900715300005, оспаривает транзакцию по карте 4400 1234 5678 9101…»
2. Уходит во внешнюю LLM (ChatGPT/Claude/Gemini):
«Клиент [PERSON_1], ИИН [NATIONAL_ID_1], оспаривает транзакцию по карте [PAN_1]…»
3. Возвращается в приложение / браузер:
«…для Ержан Нурсултанулы (ИИН 900715300005) по карте 4400 1234 5678 9101 возврат…»
Модель помогает решить задачу, пользователь получает полный ответ, а вендор не получает ни одной персональной записи[cite: 1].
Ключевая архитектура
Обратимая токенизация, а не удаление. Замена сущностей на [PERSON_1] сохраняет связность текста для LLM[cite: 1]. Соответствия хранятся только в OAM (Mapping Store) в зашифрованном виде (PRF-CTR + HMAC) и автоматически удаляются после ответа[cite: 1].
Проверка по контрольным суммам. ИИН/БИН проверяются двухпроходным весовым алгоритмом, карты — по алгоритму Луна (Luhn), IBAN — ISO 13616[cite: 1]. Секреты (AWS, OpenAI, JWT, PEM) детектируются по формату и энтропии Шеннона[cite: 1].
Zero-Dependency Core (Python 3.11+ stdlib). Поверхность атаки на Supply Chain инструмента, видящего все промпты — ровно ноль[cite: 1]. Устанавливается в Air-Gapped контур без pip install[cite: 1].
Принцип Fail-Closed. Любая ошибка распарсинга или сбой детекции блокирует запрос[cite: 1].
Tamper-Evident Audit Log. Append-only JSONL с цепочкой хешей SHA-256[cite: 1]. Любое редактирование записи нарушает целостность лога[cite: 1].
Browser Extension (Manifest V3): Перехватывает ввод в ChatGPT/Claude/Gemini прямо в браузере до отправки на сервер[cite: 1].
Endpoint Agent: Отслеживает буфер обмена (clipboard) для вставки в IDE (Cursor, Claude Desktop)[cite: 1].
Маршрутизация в локальные LLM
Можно настроить правило: промпты без ПДн идут в ChatGPT/Claude, а промпты с найденными чувствительными данными автоматически перенаправляются на локальный Ollama / vLLM (Llama 3.1)[cite: 1].
Быстрый запуск
git clone [https://github.com/oleg-vdv/AI-Gateway.git](https://github.com/oleg-vdv/AI-Gateway.git)
cd AI-Gateway
cp .env.example .env
docker compose up -d
Регуляторы скоро спросят «где у вас RSA?». Я написал сканер, который отвечает за секунды
Завязка. Три дедлайна: США — PQC для новых госзакупок нацбезопасности с 2027 (EO 14412 / CNSA 2.0, там прямо назван CBOM), Великобритания — полная криптографическая инвентаризация и план миграции к 2028 (NCSC), ЕС — переход с конца 2026. Первый вопрос аудитора одинаковый: «где именно у вас используется RSA?» Ответа нет почти ни у кого.
Что такое CBOM и почему это не то же самое, что SBOM.
«Harvest now, decrypt later» — почему это не про далёкое будущее: трафик записывают сегодня, расшифруют потом. Если у секрета срок жизни больше нескольких лет — проблема уже наступила.
Как работает сканер. Одна команда, три артефакта: CycloneDX 1.6 CBOM, отчёт с планом миграции на ML-KEM/ML-DSA, SARIF для GitHub code scanning. Плюс scan-tls — одно рукопожатие и вердикт по живому эндпоинту.
Байка про баг (Хабр это любит): первый же регрессионный тест поймал, как сканер находит «криптографию» в собственных регулярках. Лечилось маскировкой литералов RSA_generate_ke[y], и теперь есть вечный тест, что репозиторий подсвечивает только свои фикстуры.
Честный бенчмарк против PQCA CBOMkit. Не «мы лучше», а «мы разные»: CBOMkit глубже на Java/Python (знает размеры ключей, симметрику), мы шире (10+ языков, конфиги, сертификаты) и быстрее (0,05–0,12 с против минуты). Прямая ссылка на docs/BENCHMARK.md — воспроизводимо кнопкой в CI.
Ограничения честно: v0 на паттернах, динамические вызовы пропустит, отсутствие находок ≠ отсутствие проблем. AST-движок в планах.
Финал: вопрос к читателям — у кого уже спрашивали CBOM и в каком виде.
OpenAPI React скомпрометирована в результате атаки на цепочку поставок npm от Mini Shai-Hulud
28 августа 2026 года в npm появились десять вредоносных версий @7nohe/openapi-react-query-codegen. Согласно предупреждению проекта, при установке они запускали код атакующего на машине разработчика или CI-раннере. Под угрозой оказались секреты GitHub, облачных сервисов и реестров пакетов.
За неделю с 23 по 29 августа пакет скачали 156 752 раза. На вредоносные версии пришлось около 1 900 загрузок, и доступны они были меньше двух суток. В пакетной базе npm также находится 8 зависимых пакетов, у которых есть указание использования вредоносного пакета. Это показывает размер потенциально задетой области, а не число подтвержденных заражений.
CodeScoring завел эти версии в базу 29 августа в 02:20 по Москве, через девять минут после публикации предупреждения GitHub, и еще через две минуты они попали под блокировку в платформе. Все десять помечены как опасные, поэтому у пользователей платформы данные компоненты автоматически блокируются при наличии соответствующей политики безопасности.
Атакующему не понадобилось взламывать учетную запись автора пакета. Ошибка была в workflow публикации. Любой пользователь мог открыть pull request из форка и запустить этот сценарий специальным комментарием. GitHub Actions загружал код из pull request и устанавливал зависимости, хотя одновременно имел право публиковать пакет в npm.
По сути, внешний пользователь на несколько минут получал полномочия доверенного издателя. После атаки мейнтейнер проекта убрал запуск публикации по комментариям, отозвал связанные полномочия и оставил выпуск версий только по тегам.
Вредоносный код запускался во время установки пакета. В части версий запуск был прописан в команде preinstall внутри package.json, которую npm выполняет перед установкой. В других ту же команду спрятали в binding.gyp — конфигурационном файле для сборки нативных модулей с помощью node-gyp. Поэтому проверка только скриптов в package.json не обнаружила бы все зараженные выпуски. Полезная нагрузка искала учетные данные и настройки инструментов разработчика, а затем пыталась распространяться через доступные пакеты и репозитории. Механика похожа на августовскую волну Shai-Hulud, только точкой входа стала не учетная запись мейнтейнера, а небезопасный процесс публикации.
Все зараженные версии при этом получили валидные сведения о происхождении сборки (provenance). Это важная граница такой проверки. Она подтверждает, где собрали и опубликовали пакет, но не доказывает безопасность самого процесса. В данном случае сборка действительно прошла через официальный процесс публикации проекта, который, однако, выполнил код из чужого pull request.
Сейчас основной тег пакета снова указывает на чистую версию 3.0.2, а зараженные релизы удалены из NPM. Удаление пакета из реестра остановит новые установки, но не вернет уже украденные секреты. Командам стоит:
если пакет устанавливался 28 августа с разрешенными установочными скриптами, пересобрать машину или CI-раннер из чистого образа и отозвать секреты, доступные в этой среде;
очистить кэш пакетного менеджера и повторить установку с чистой версией;
проверить автоматические сценарии публикации: в них нельзя исполнять код из pull request внешних участников с правами на выпуск релизов.
Пользователям CodeScoring достаточно один раз настроить блокирующую политику с условием «Зависимость опасна». Пример настройки данной политики можно найти в документации платформы.
Новый закон об ИИ вступает в силу 1 сентября: что изменится для владельцев сайтов
Привет! Я Александр Бондаренко, руководитель проектной группы в Далее. Мы делаем сайты и плотно работаем с их комплаенсом, поэтому новые законы я изучаю не как новости, а как список требований к проектам.
В сентябре вступил в силу новый закон об ИИ, вокруг которого ходит много слухов. В интернете пишут, что иностранные нейросети теперь под запретом, а сгенерированный контент обязательно придется маркировать. Но если прочитать реальный текст документа, открывается другая картина.
В этом посте разберу, кого закон касается на самом деле, что изменится для владельцев сайтов и какие вопросы пока остаются без ответа.
Сначала напомню, о каком законе идет речь👇
Федеральный закон № 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации»
Рамочный закон, который регулирует большие фундаментальные модели вроде ГигаЧата или Алисы. Они имеют от 1 миллиарда параметров и способны выполнять интеллектуальные задачи на уровне человека или выше. Если компания просто использует готовые модели в своих сервисах, закон на нее напрямую не распространяется.
Основная часть закона вступает в силу с 1 сентября 2026 года, отдельные нормы — с 1 марта 2027-го.
Закон вводит статус суверенной или национальной модели. Его могут получить только разработчики, которые хранят и обрабатывают данные в России и используют открытые лицензии для сторонних компонентов. Еще по закону контролирующие лица не должны иметь второе гражданство.
Суверенные модели смогут использовать контент с сайтов без согласия авторов
Национальный статус дает два преимущества: можно свободно обучаться на объектах авторского права и получить доступ к государственным данным.
С 1 марта 2027 года модели с особым статусом будут использовать статьи, книги, музыку и изображения бесплатно и без отдельного разрешения автора. При условии, что произведение было получено правомерно или легально опубликовано и доступно для анализа.
Это классический механизм opt-out: нейросеть по умолчанию может парсить и анализировать контент, если владелец заранее не ограничил это право. Пока непонятно, какой именно технический сигнал признают достаточным ограничителем — это открытый вопрос и в российской, и в европейской практике, где действует похожая логика.
Обязательная маркировка ИИ-контента — просто слух
Его часто повторяли в интернете, пока закон проходил согласования. По факту же маркировка добровольная, обязательна только техническая возможность ее поставить, и только для крупных платформ.
Разработчики моделей с аудиторией до 500 000 могут опционально добавить функцию маркировки для пользователей. Для платформ с посещаемостью выше — это обязательное требование. Если ваш сайт или сервис близок к этому порогу аудитории и работает с генеративным контентом, стоит заранее продумать, как это реализовать.
Прямого запрета на использование иностранных моделей в законе нет
Правительство сможет регулировать объекты и сферы, где разрешено применять только суверенные модели. Подробностей пока нет, но мы знаем, что будет поблажка. Если система уже работает к 1 марта 2027 года и данные хранятся в России, владельцы смогут использовать иностранный ИИ до сентября 2032 года.
Отдельно закон выделяет финансовый сектор. Здесь решения Правительства должны приниматься по согласованию с Банком России. Поэтому банкам и финтех-компаниям стоит следить не только за подзаконными актами Правительства, но и за будущими требованиями ЦБ.
Некоторые вопросы остаются открытыми
Какие государственные данные откроют для обучения?
Как будет работать opt-out и каким будет технический механизм отказа правообладателя?
Где будут разрешены только суверенные модели и насколько широким будет этот список?
Что такое достаточная «техническая возможностью маркировки»?
Если подытожить, то сейчас закон задал общую рамку, но мы все еще ждем конкретики. Пока подписывайтесь на канал «Согласен на обработку»: там я разбираю новые законы о данных, рекламе и ИИ.
В сентябре покажем, как за пять дней построить Data Lakehouse, защитить данные при работе с LLM, выстроить безопасную ИИ-инфраструктуру и обеспечить отказоустойчивость PostgreSQL для продакшен-нагрузок. Выбирайте интересную тему и регистрируйтесь.
Как построить управляемый Data Lakehouse за неделю на Evolution Data Platform Покажем, как за несколько дней с нуля построить архитектуру Data Lakehouse на Evolution Data Platform — от загрузки сырых данных до курированных витрин. Разберем принципы работы с Apache Iceberg, централизованное управление метаданными, контроль качества данных, единый SQL-слой и оркестрацию пайплайнов. Все увидите на демо. 🧑💻 Для кого: архитекторы данных, дата-инженеры, руководители аналитики и data-направлений, ИТ-директора, специалисты по управлению данными. 📅 Когда: 8 сентября, 11:00 мск. 📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
Как защитить чувствительные данные при работе с LLM с помощью Guardrails Разберем, как работают Guardrails LLM и Guardrails Filter: чем они отличаются, какие данные помогают обнаруживать и как адаптировать правила проверки под задачи компании. Отдельно рассмотрим, как защитный слой Guardrails работает в контуре Evolution Foundation Models, а также какую роль в проверке запросов играют модели-классификаторы HiveTrace. На демо покажем работу open source версии Guardrails Filter. 🧑💻 Для кого: специалисты по защите данных и ИБ, команды разработки ИИ-приложений и тем, кто внедряет LLM в бизнес-процессы. 📅 Когда: 15 сентября, 11:00 мск. 📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
ИИ в облаке: кто отвечает за безопасность Безопасность ИИ в облаке — это общая ответственность провайдера и бизнеса. Разберем, где проходят границы этой ответственности и как выстроить безопасную ИИ-инфраструктуру без лишних рисков. Обсудим подход Zero Trust: расскажем, как контролировать доступ к данным, моделям и сервисам в Cloud.ru Evolution и какую роль в этом играет Evolution Managed Identities (IAM). 🧑💻 Для кого: руководители и специалисты по ИБ (CISO), архитекторы и инженеры, проектирующие ИИ-инфраструктуру, специалисты, работающие с чувствительными данными, руководители, отвечающие за внедрение ИИ в компании. 📅 Когда: 17 сентября, 11:00 мск. 📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
PostgreSQL для продакшен-нагрузок: Multi-AZ, реплики и переключение ролей От доступности PostgreSQL зависит стабильная работа backend-сервисов и пользовательских сценариев. Разберем, как обеспечить высокую доступность PostgreSQL в облаке. Покажем, как в Evolution Managed PostgreSQL устроена архитектура Multi-AZ, какую роль играют реплики базы данных и как работают ручное и автоматическое переключение при плановых работах и сбоях. 🧑💻 Для кого: DevOps-инженеры, SRE-инженеры, инфраструктурные инженеры и все технические специалисты, работающие с PostgreSQL. 📅 Когда: 29 сентября, 11:00 мск. 📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.
Много лет висело без откликов у меня на hh.ru резюме на вакансию «Web-реаниматор старых сайтов» и вдруг прилетела «подработка»…
У небольшой организации занимающейся разработкой очень специфичной техники есть в интернете несколько информационных сайтов на Joomla 3 и уже года 4 без каких-либо изменений, и, соответственно без необходимости иметь сотрудника для их поддержки. И что примечательно, у этих сайтов в среднем около 1 посещения в неделю..
Но месяц назад на двух сайтах вдруг появились вместо заглавных страниц сообщения «Взломан CoupDeGrace» и «Взломан ANTONKILL». Так у меня появилась хоть какая-то работа за последние 4 года. Убрать заставки взломщиков оказалось достаточно просто, сложнее перекрыть дальнейшие возможности для подобных хулиганств – не представляю как удалить из работающего сайта модули Helix и Sppagebuilder, через которые происходит основной вход «хулиганов»… частично их «деактивировал». Но наверняка есть и другие способы, про которые я тогда не знал. Обновлять Joomla до актуальной версии занятие долгое и непредсказуемое, а потому один сайт остался жить просто почищенным от заставок «Взломан …», а их там оказалось несколько десятков, а другой достаточно быстро перелопачен в статичные html страницы. Первый этап «реанимации» закончен и очень постепенно начался второй – поиск нового движка для сайтов. Желательно отечественного производства, с активной поддержкой, чётким MVC, а ещё и бесплатным… в общем – проблематичные условия, но несколько кандидатов нашлось, и даже лидер образовался с самым маленьким количеством проблем на входе.
Но опять возникло «НО»! Тот сайт, что остался крутиться на Joomla был заселён несколькими бэкдорами и это обнаружилось совершенно случайно только потому, что развили очень активную деятельность и буквально подвесили виртуальный сервер с очень скромными ресурсами.
За прошедшие выходные я понял, что мои возможности уже сильно устарели и резюме на вакансию «Web-реаниматор» надо бы убрать… Мало того, что «искусство обфусцирования» вышло за уровни моего понимания, но как можно перехватывать пересылаемый по ftp на сайт index.php и класть его в корень с уже вписанным «вирусом» - мне уже видимо не осознать.
В прошлом году на секции «Слабое звено ИБ» один выступающий рассказал о своём эксперименте по «взлому» - всего $10 долларов на оплату токенов и ВСЁ! Про миллион за взлом «белым хакерам» можно забыть – нейросети обесценили труд этих специалистов на несколько порядков.
Любая известная и популярная CMS со средствами «web-администрирования» и самообновления уже имеет в себе «парадные ворота» для взлома и заселения всем чем захочется.
На мой «устаревший» взгляд, самым эффективным вариантом решения проблемы для подобных информационных сайтов, мне видится CMS с полным функционалом по управлению сайтом на локальном компьютере, а в «публичное пространство» выгружаются только html страницы. И только 555 для папок и 444 для файлов.
А может не всё так грустно? Может есть уже простые решения, про которые всем кроме меня всё давно известно?
ФСТЭК готовит новые требования к защите ИИ: как службе ИБ сохранить контроль
Использование ИИ в организациях становится отдельной задачей для информационной безопасности: вместе с новыми возможностями появляются требования к контролю ИИ-контуров, взаимодействия с моделями и защите данных.
ФСТЭК России предложила изменения в приказ №117. Если проект примут, с 1 марта 2027 года появятся дополнительные требования к защите ИИ.
Среди предлагаемых мер:
сетевая изоляция моделей;
многофакторная аутентификация;
применение принципа наименьших привилегий;
фильтрация запросов и ответов;
ограничение количества обращений к модели;
контроль функциональности ИИ.
При этом это не первые требования регулятора к ИИ. Уже сейчас организации должны определять границы ИИ-контура и его активы, устанавливать допустимые тематики контента, а также правила обнаружения и реагирования на события и инциденты.
Как службе ИБ сохранить контроль над ИИ? Один из практических вопросов — контроль взаимодействия между ИИ-приложением и языковой моделью: выявление чувствительных данных, доступ только к утверждённым моделям и передача событий ИБ в SIEM. Отдельная задача — контроль использования сотрудниками публичных ИИ-чатов, или Shadow AI.
Эти и другие вопросы защиты корпоративного ИИ разберём 10 сентября в 11:00 МСК на вебинаре «Корпоративный ИИ захватывает всё больше бизнес-процессов. Как службе ИБ сохранить контроль?»
Айдар Фатыхов, владелец продукта Innostage AIDR, и Александр Лебедев, старший ML-разработчик продукта Innostage AIDR расскажут:
как защитить коммерческую тайну и другие чувствительные данные при работе с ИИ;
почему события ИБ от ИИ-систем необходимо включать в процессы мониторинга, корреляции и расследования инцидентов;
какие требования к защите ИИ действуют сегодня и что предлагается изменить в приказе ФСТЭК России №117.
в практической части вебинара покажут сценарии защиты запросов и ответов LLM, утечки данных и контроля Shadow AI.
ФСТЭК готовит новые правила для ИИ в государственных информационных системах. 24 августа ведомство опубликовало проект изменений в приказ №117. В нем предлагается ограничить модели ИИ в доступе и правах. Проект должен вступить в силу 1 марта 2027 года.
Что меняется, когда ИИ получает доступ к LDAP
ИИ сильно повзрослел. Это уже не просто собеседник, а полноценный агент, который может сам обращаться к компьютерам, серверам и выполнять операции.
Например, если ИИ-агенту дать доступ к корпоративному LDAP-каталогу, он сможет:
Добавить учетную запись в группу
Изменить атрибут пользователя
Изменить членство в группе
Массово изменить данные
Поэтому, если злоумышленник получит доступ к агенту, то он сможет украсть или испортить данные каталога, передать их в третьи руки.
Что может оказаться под угрозой?
В каталоге лежат не только логины и учётные записи, но и ФИО, должности, отделы, телефоны, почта, фото – целая база персональных и служебных данных.
Если агенту разрешено читать эти данные, то злоумышленникам не обязательно взламывать LDAP. Достаточно дать агенту команду – и он сам отдаст данные наружу или испортит их.
Локальная или внешняя модель?
С точки зрения рисков не принципиально, используете вы внешнюю или локальную модель. Если локальная модель имеет широкие права, она сольёт данные не хуже внешнего сервиса. Так что ФСТЭК смотрит не на место проживания модели, а на то, что она видит, к чему имеет доступ и что может делать.
Один неправильный запрос может превратиться в инфраструктурный инцидент.
Причем источник проблемы может находиться далеко от каталога. Например, вредоносная инструкция может попасть в ИИ через внешний ресурс или заражённый документ. Эксперты называют prompt injection одной из главных дыр, которые надо закрывать в защите ИИ.
ИИ становится еще одним участником системы доступа
Выходит, ИИ-агент, подключенный к каталогу, становится еще одним участником системы управления доступом. Если дать ему слишком много прав, мы откроем путь: внешняя команда → ИИ-агент → LDAP → данные пользователей или права доступа.
Поэтому принцип минимальных прав критичен. Если агенту нужен только один атрибут – не даём ему весь каталог. Если нужно сделать одну операцию – не разрешаем править все учётки. Чем меньше прав, тем меньше ущерб от возможной атаки.
Что делать, если изменения уже произошли
Просто иметь бэкап каталога – мало. Если агент испортил сотни записей, полный откат вернёт старую версию, но заодно откатит все правильные изменения, которые появились после бэкапа.
Поэтому нужны два уровня защиты:
Резервное копирование, чтобы сохранить состояние каталога;
Гранулярное восстановление, чтобы найти и вернуть неправильно изменённые объекты или атрибуты.
Получается простая цепочка:
ограничить права ИИ → контролировать его действия → не дать слить данные наружу → не дать править лишнее → иметь бэкап → уметь точечно восстановить данные.
Новые требования ФСТЭК интересны не только для ИИ. Они показывают: если ИИ подключается к инфраструктуре, его безопасность становится частью безопасности всей системы – включая службу каталога.
Полезные онлайн-ресурсы с актуальными и отчётами по информационной безопасности:
Annual Security Reports — репозиторий, который включает в себя ежегодные отчёты по кибербезопасности от крупнейших IT-компаний.
Phishing campaigns — репозиторий с примерами фишинговых писем, которые направлялись APT‑группировками в различные компании по всему миру. Помимо примеров, проект включает в себя презентации с разбором и описанием фишинговых атак.
Hackerone Reports — объёмный репозиторий,который включает в себя топ отчёты HackerOne. Поможет узнать много нового и полезного (варианты эксплуатации различных уязвимостей, векторы атак и так далее).
Специалистам по информационной безопасности приходится работать с огромным количеством данных: логами, алертами систем мониторинга, обращениями пользователей. Среди них могут скрываться признаки атаки — вручную разбирать такой объем информации сложно.
Часть этой работы можно ускорить с помощью ИИ. Вместе с Евгением, специалистом по безопасности приложений в Naumen, разобрали, где ИИ действительно полезен и какие ограничения важно учитывать.
1️⃣ Как ИИ помогает разбирать инциденты?
После обнаружения инцидента нужно собрать информацию из разных источников, найти связи между событиями и восстановить их последовательность.
ИИ может проанализировать логи и другие данные и собрать их в понятную картину.
Например, пользователь получил подозрительное письмо, перешел по ссылке, установил ПО, после чего в системе появился подозрительный процесс.
2️⃣ Как ИИ помогает проверять защищенность приложений?
ИИ может анализировать структуру приложения, подсказывать наиболее вероятные точки входа и обращать внимание на потенциально опасные участки.
Еще один сценарий — помогать генерировать полезные нагрузки для проверки уязвимостей, в том числе с учетом конкретных механизмов защиты. А после тестирования — быстрее подготовить итоговый отчет.
3️⃣ Может ли ИИ находить уязвимости еще на этапе разработки?
Да. Современные модели умеют находить типовые веб‑уязвимости — например, SQL‑инъекции, XSS и CSRF, — участвовать в ревью кода и объяснять, почему выбранный подход может быть опасен.
Еще ИИ может переводить технические отчеты сканеров уязвимостей на более понятный язык, давать рекомендации и помогать приоритизировать проблемы.
4️⃣ Где еще он может пригодиться?
Например, в обучении сотрудников. С помощью ИИ можно создавать реалистичные сценарии фишинговых атак и учебные кейсы, формировать индивидуальные траектории обучения или переводить ГОСТы, ISO и внутренние регламенты на более понятный язык.
5️⃣ Какие ограничения важно учитывать?
Код, написанный с помощью ИИ, сам может содержать проблемы безопасности, поэтому его нельзя принимать без ревью.
Отдельный вопрос — работа с чувствительными данными. Для таких сценариев разумнее использовать локальные модели без доступа в интернет.
Кроме того, сама модель может стать целью атаки. Поэтому при внедрении ИИ важно продумывать, какие данные доступны модели, как она взаимодействует с внешними сервисами и как проверяются результаты ее работы.
→ Подробнее своим опытом Евгений поделился в статье.
Бот с заданиями по кибербезопасности и розыгрыш мерча
Каждый год у нас в Ozon Tech проходит турнир Capture The Flag. И каждый раз после его окончания мы делимся заданиями с подписчиками. За правильные флаги самым удачливым дарим мерч.
В этом сезоне наш гусь-маскот Гоша отправился в путешествие в далёкие-далёкие галактики. По пути он попал сразу в пять приключений формата OSINT, Forensic и Stego. Пришлось дешифровать тревожные сигналы, ловить акустические аномалии, декодировать координаты.
MAX тоже можно защитить шифрованием поверх мессенджера
Telegram, VK и другие сервисы можно использовать как транспорт для зашифрованных сообщений, не полагаясь на их собственный механизм защиты содержимого. Российский разработчик развивает open-source проект CryptoLayer — библиотеку, которая создает дополнительный криптографический слой непосредственно на устройствах участников переписки.
Идея простая: мессенджер становится каналом доставки. Сообщение сначала шифруется локально, затем полученные данные отправляются через выбранный сервис. На устройстве получателя они восстанавливаются и расшифровываются.
Как это работает
CryptoLayer не заменяет Telegram, VK или другой сервис, а отделяет защиту содержимого от транспорта.
Для шифрования используется AES-256-GCM, для цифровых подписей — ECDSA на кривой SECP256R1, а согласование ключей выполняется через ECDH с той же кривой. Дополнительно библиотека может преобразовывать зашифрованные данные с помощью WordCoder — он кодирует байты в последовательность обычных слов.
В результате транспорт получает не исходный текст, а набор слов, который не содержит исходного смыслового содержания. На стороне получателя последовательность преобразуется обратно в байты, после чего CryptoLayer выполняет расшифровку.
Один криптографический слой — разные каналы
Главная особенность проекта — модульная архитектура. CryptoLayer не привязан к конкретному мессенджеру или платформе.
В репозитории указано, что транспортом может быть практически любой канал, способный передавать данные. Среди примеров — Telegram, VK, Discord, HTTP, SSH, FTP, UDP, облачные хранилища, файловая система и Bluetooth. Для нового варианта передачи требуется написать отдельный модуль.
Такой подход позволяет использовать одну криптографическую часть поверх разных сервисов. Теоретически это относится и к MAX: для него можно создать отдельный транспортный модуль, не меняя ядро библиотеки.
Однако готового модуля для MAX в основном репозитории сейчас нет. Поэтому полноценной поддержки этого мессенджера пока нет — потребуется отдельная интеграция.
Какие инструменты уже доступны
Вокруг CryptoLayer постепенно формируется собственная экосистема:
CryptoLayer CLI — интерфейс для работы из терминала;
CryptoLayer Web UI — веб-интерфейс для защищенного обмена сообщениями;
zkgram — отдельный клиент для приватного общения через Telegram.
Исходный код опубликован под лицензией MIT. На момент проверки официальный репозиторий набрал более 200 звезд на GitHub, но проект остается небольшим независимым open-source решением, а не криптографической системой, прошедшей масштабный аудит.
Это важная оговорка. Наличие AES-256-GCM, ECDSA и ECDH само по себе не гарантирует безопасность всей системы. Многое зависит от реализации протокола, генерации и хранения ключей, защиты конечных устройств и отсутствия ошибок в коде.
Что все равно видит мессенджер
CryptoLayer решает конкретную задачу: защищает содержимое сообщения от транспортного сервиса. Но он не скрывает сам факт общения и не делает пользователя анонимным.
Мессенджер по-прежнему может получать техническую информацию, необходимую для работы платформы: данные аккаунтов, факт передачи сообщений, время активности и другие метаданные.
Иными словами, CryptoLayer не скрывает существование переписки. Его задача — не дать транспортному каналу получить исходный текст сообщения.
Где посмотреть исходный код
Репозиторий CryptoLayer на GitHub содержит исходный код, описание архитектуры, используемые криптографические механизмы и информацию о доступных интеграциях.
CryptoLayer интересен не как новый защищенный мессенджер, а как внешний слой шифрования, который отделяет конфиденциальность переписки от конкретного сервиса доставки.
Если проект продолжит развиваться, один и тот же криптографический механизм можно будет использовать поверх разных каналов.
