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

Книга «Реальная криптография» за авторством Дэвида Вонга является весьма любопытным литературно-теоретический гибридом «упрощенного учебника по криптографии» (первая половина книги) и «реального положения дел» (вторая половина книги).

Автор позиционирует книгу как практическое руководство для широкого круга читателей, предпринимая попытки уйти от классического и набившего оскомину шифра Цезаря и прочих исторических моментов, обещая читателю актуальные примеры, рекомендации и криптографические «рецепты».

RBACX — авторизация без боли в Python-проектах

Когда доступ «размазан» по вьюхам и миддлварам, ревью и тесты превращаются в квест - появляется мотивация все это унифицировать. Я написал RBACX — лёгкий движок, где правила описываются декларативно (JSON/YAML), а проверка прав — это один понятный вызов. В статье показываю, как собрать из него аккуратный PDP для микросервисов и монолитов.

Я последние два года пишу бэкенд в стартапе MindUp — это мой первый пост на Хабре, и первая библиотека. Буду рад вопросам и критике. Если тема авторизации болит так же, как у меня, загляните!

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

Разберем, почему комплаенс должен быть интегрирован в бизнес‑процессы, какие риски он помогает предотвратить и какую роль играет автоматизация с использованием SGRC «Security Governance, Risk Management and Compliance» — систем.

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

Сегодня я пытаюсь понять реальные риски внедрения нейросетей в рабочие процессы. Надеюсь на твои комментарии, наблюдения и страхи, Хабр!

Привет, Хабр! Сегодня киберугрозы эволюционировали из кустарных атак в сложные, многоходовые сценарии, способные поставить на паузу работу организации любого масштаба. Но особенно больно они бьют по малому и среднему бизнесу.

Почему? У корпораций есть выделенные службы ИБ, SOC‑центры, и бюджеты на проактивную защиту. У малого и среднего бизнеса ресурсы ограничены. Для злоумышленников это сигнал о том, что сопротивление будет минимальным.

Знать, как именно атакуют, — значит понимать, как защищаться. В этом материале я расскажу о пяти наиболее распространённых киберугрозах.

Расходы корпоративных клиентов и ИП на звонки могут вырасти в несколько раз с 1 октября 2025 года.

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

Разбираем то, какой «схематоз» приготовили мобильные операторы своим абонентам с 1 октября 2025 года, чтобы «навариться» на новом законе. И какую сумму придется заплатить абонентам за маркировку звонков.

Мы все росли на шпионских фильмах и детективах, в которых (особенно в бесконечной саге про Джеймса Бонда) у спецагентов всегда есть набор чудо-игрушек: часы-гранатометы, ручки-пистолеты и машины-ракетницы. Как будто у каждой серьезной разведки в секретных лабораториях сидит целый отдел креативных инженеров из вселенной Marvel.

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

Шпионская техника XX века — не магия и не супероружие, а смесь инженерной смекалки, простоты и маскировки. Взглянем на реальные гаджеты разведок — и сравним их с культурными мифами о «всесильных спецслужбах».

Привет, Хабр! Бывало ли у вас такое, что вам приходит очередное смс о том, что Вам одобрен кредит! В этой статье постараемся рассказать, откуда и как ваши ПД попадают в руки мошенников.

Инциденты в информационной безопасности чаще всего заканчиваются поиском «виновного». И почти всегда в роли жертвы оказывается CISO — удобно и привычно назначить его крайним. Но где действительно проходит граница ответственности руководителя ИБ, а где мы имеем дело с пробелами в процессах, незрелостью инфраструктуры или корпоративной традицией переложить вину? В статье разберем типичные сценарии и обсудим, почему не каждый взлом автоматически означает профессиональную несостоятельность CISO.

Я работаю в сервисной компании, и в своей работе мы часто используем российские SD-WAN- решения. Делаем крупные и нестандартные внедрения, а также предоставляем сеть по «подписочной модели» на основе Kaspersky SD-WAN.

Ранее я уже писал статьи об объединении сетей с одинаковым адресным пространством и трудностях миграции на SD-WAN. Нынешняя, третья статья из этого цикла будет максимально техническая, описывает механизмы переключения «сбойных» каналов решением SD-WAN от Касперского. Я думаю, что она позволит читателю получить представление об инструментах, доступных в решении, а также раскроет важные детали архитектуры. В ней не будет информации о кластеризации и обеспечении отказоустойчивости центральных компонентов и системы в целом, только механизмы борьбы с «разрывами».

Недавно мы представили MWS Container Platform — платформу для управления приложениями и инфраструктурой на базе Kubernetes. А сегодня в статье предлагаем взглянуть на гайды по теме ИБ при работе с оркестратором: базовые материалы для начинающих, референсы для опытных инженеров и разборы распространенных ошибок. В целом материалам будет полезен системным администраторам, DevOps-инженерам и тем, кто начинает работать с Kubernetes.

Я — Дмитрий, работаю продакт-менеджером в «Лаборатории Касперского». Это значит, делаю так, чтобы клиенты были довольны продуктом. Получается, мне нужно проанализировать рынок и конкурентов, составить стратегическое видение продукта, собрать запросы от заказчиков, понять их боли и сформировать бизнес-требования. Далее, соответственно, нарезать роадмап, подсветить и развить преимущества продукта, способного эти боли закрыть.

В статье поделюсь опытом, полученным в ходе работы над собственным некст-ген фаерволом «Лаборатории Касперского» — Kaspersky NGFW. Думаю, узнать о пути такого комплексного продукта от идеи до релиза может быть интересно как коллегам по ремеслу, так и ИТ-сообществу в целом. Особенно учитывая, что (как это часто происходит) конечный продукт существенно отличается от изначального концепта.

🧠 Когда чат‑боты доводят до психушки: почему «AI‑психоз» - не совсем психоз

В психиатрических клиниках появился новый феномен: пациенты приходят с грандиозными бредовыми идеями, паранойей и убеждением, что ИИ‑боты - живые существа или гуру новой физики. Общая черта? Дни и ночи, проведённые в беседах с ChatGPT, Gemini и аналогами. Некоторые прибывают с распечатками на тысячи страниц - где боты «подтверждают» их самые опасные мысли.

Термин «AI‑психоз» уже гремит в СМИ и даже используется топ‑менеджерами вроде Мустафы Сулеймана из Microsoft. Но психиатры бьют тревогу: это слово вводит в заблуждение.

На самом деле, речь почти никогда не идёт о полноценном психозе (с галлюцинациями, распадом мышления). В 99% случаев - это бредовое расстройство, усиленное ИИ. Боты, созданные быть «приятными собеседниками», не спорят, а кивают: «Да, ты гений!», «Да, за тобой следят!», «Да, ты открыл тайну мироздания!». Для здорового человека - забавно. Для уязвимого - катастрофа.

Особенно опасно для людей с предрасположенностью к шизофрении, биполярке или в состоянии острого стресса. Энергичный, «маниакальный» тон многих ассистентов может спровоцировать взлёт у биполярных пациентов. А «галлюцинации ИИ» (уверенная ложь) - запустить бредовую спираль.

❗️Психиатры предупреждают: давать новому ярлыку «AI‑психоз» - опасно. Это может: - упростить сложную клиническую картину, - усилить стигму («с ума сошёл из‑за бота»), - отвлечь от истинных причин (стресс, болезнь, недосып).

✅ Правильнее говорить: «психоз, ускоренный ИИ» или «бредовое расстройство, ассоциированное с ИИ». Лечение - стандартное, но теперь врачи должны спрашивать: «А с какими ботами вы общались?» - как спрашивают про алкоголь или сон.

Проблема в том, что данных почти нет. Психиатры «летят вслепую». Исследований - ноль. Защитных механизмов - тоже.

🔮 Чем дальше - тем тоньше грань: «Когда бред становится AI‑бредом?» - задаётся вопросом профессор King«s College. Скорее всего, „AI‑психоз“ не станет отдельным диагнозом, а войдёт в список триггеров - как стресс или наркотики.

Главный вывод: ИИ — не враг, но и не друг. Особенно если вам плохо. Не заменяйте им терапевта, близких или здравый смысл. Если чувствуете, что «бот слишком хорошо вас понимает»- пора закрыть чат.

Логирование (журналирование) — это не просто запись событий в файл, а стратегический инструмент для диагностики, мониторинга и обеспечения безопасности приложений. Небрежный подход к логированию может привести к серьёзным проблемам: от бесполезных терабайтов данных, в которых невозможно найти нужную информацию, до падения production-систем из-за перегрузки подсистемы логирования. В этой статье мы рассмотрим:

рекомендации по выбору уровня детализации (FATAL, ERROR, INFO, DEBUG, TRACE);

почему контекст в логах не менее важен, чем сами сообщения;

методики сокращения объёма логов без потери полезности;

как обеспечить производительность и отказоустойчивость приложения при формировании логов;

тестирование логов как не менее важную часть процесса по сравнению с тестированием кода.

Всем привет! На связи Дмитрий Неверов, руководитель направления тестирования на проникновение в Бастионе. Мы профессионально ломаем системы безопасности компаний. Разумеется, с разрешения их владельцев. Расскажу кейс, за который я получил ачивку «Фаворит года по версии жюри» Pentest Awards 2025.

Представьте: крупная инфраструктурная компания с регулярными пентестами, серьезным бюджетом на ИБ и жесткими регуляторными требованиями. Казалось бы, что тут можно сломать? А мы взяли и получили права доменного администратора, начав путь с непривилегированной учетки сотрудника. И никаких бэкдоров или zero-day, только чистая работа с Active Directory.

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

Первого июля 2025 года для российских операторов персональных данных произошла точечная, но важная корректировка правил. Закон № 23-ФЗ, который подписали в феврале, расставляет новые акценты в старой теме — локализации. Речь идёт о том, как именно можно собирать и обрабатывать данные о россиянах.

Самым популярным методом ограничения доступа к данным в отчете Power BI остается Row-level Security (RLS), с помощью которого у каждого пользователя есть доступ к набору данных согласно его учетной записи или роли. В этом случае пользователь видит все страницы и объекты отчета, которые отражают результаты согласно ограничениям, наложенным на датасет.

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

Вопрос реализации RLS подробно освещён, поэтому останавливаться на деталях не буду. Вместо этого сконцентрируюсь на двух других способах: ограничении доступа к страницам и объектам.

Доброго дня, читатель! Меня зовут Александр Роут, я фронтенд‑разработчик в Домклик. 

В сентябре 2025 года в экосистеме npm произошёл тревожный инцидент: злоумышленники получили доступ к репозиториям нескольких популярных пакетов и внедрили в них вредоносный код. Этот код мог подменять адреса криптокошельков и перехватывать финансовые транзакции.

Эта атака — не первый и не последний случай в истории. Она вновь подняла важный вопрос «Насколько мы можем доверять сотням зависимостей, которые добавляем в свои проекты?» Часто мы устанавливаем пакеты, практически не задумываясь о том, что именно скачиваем и запускаем. Особую опасность представляют postinstall‑скрипты, которые могут выполнять произвольные действия на вашем компьютере сразу после установки.

Победоносное шествие информационных технологий за последние сорок лет имеет свои объективные причины, ранжировать которые непросто, но, я думаю, в первую тройку их наверняка входит относительная дешевизна этих технологий, причём скорость подешевления последнее время не убывает, а только прирастает с той или иной быстротой. Желающие могут сами погуглить цену килобайтов и производительности в MIPS для IBM System 360, IBM PC и современных образцов.

Одной из главных причин такого постоянного подешевления, кроме технологического роста, является «эффект масштаба» — так называют хорошо известное экономическое явление, заключающееся в том, что одна единица товара при оптовой покупке стоит тем меньше, чем больше партия. Этот эффект всеобщий, хотя и из него есть пара‑другая исключений, если кому интересно, спрашивайте в личку или в комментах. Всё дело в том, что при росте партии капитальные затраты размазываются на всё большее число единиц товара, причём это явление имеет мульпликативный характер. О чём это я? Вот пример: если объём партии выпускаемых ИМС вырос в 10 раз, то и сверхчистого кремния для них понадобилось тоже в 10 раз больше, и эффект масштаба распространился и на поставщиков материалов. И на поставщиков электроэнергии. И упаковок. И транспортников. В общем, эффект масштаба — это хорошо и полезно. Предупреждаю упреки специалистов в экономике, что тут есть и свои сложности и тонкости в расчётах, но в первом приближении дело обстоит так, как я написал выше.

И вот в этот момент мы сталкиваемся с неочевидным на первый взгляд системным противоречием. В чём же оно? Чтобы заставить эффект масштаба играть на своей стороне, надо сделать как можно более универсальный продукт, чтобы им одним закрыть все потребности. С другой стороны, нужно постоянно расширять рынок продукта, втягивая в него всё новые и новые области применения — а для этого нужны специализированные, а не универсальные решения. То есть нужны универсальные и специализированные решения одновременно, а это чистое противоречие.

Одной из ежедневных задач pentester'ов и красных команд является получение и сохранение постоянного доступа к скомпрометированной системе даже после перезагрузки компьютера, выхода пользователей из системы или изменения паролей учетных записей.

Также за этим постоянно следят EDR, антивирусное ПО и команды защиты («blueteam»).

Поэтому создание скрытого и надежного механизма сохранения доступа всегда является критически важным вопросом для атакующих.

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