Вакансии по пентесту всё чаще требуют не только понимания принципов работы ключевых СЗИ (WAF, EDR, NAC), но и практических навыков их обхода. То же самое касается EDR/AV. В реальных отчётах о кибератаках также регулярно упоминается, как злоумышленники обходят средства защиты и остаются незамеченными.
Предлагаем рассмотреть пару приемов таких обходов и проверить, готовы ли ваши системы защиты к подобным вызовам.
LLM умеют многое: генерировать тексты, анализировать документы, писать код. Но на практике их работа часто непредсказуема — сегодня модель даёт точный ответ, а завтра на тех же данных ошибается, пропускает ключевые шаги или придумывает факты.
Для AI-инженеров это системная проблема. Возьмём автоматизацию документооборота: нужно классифицировать договоры, извлекать реквизиты, проверять стандарты. Но модель работает как лотерея — результат не поддаётся логике или меняется при повторном запуске с одинаковыми данными. Как встроить такой результат в бизнес-процесс?
Для решения этой задачи появился подход Schema-Guided Reasoning (SGR). Его активно продвигает Ринат Абдуллин в материалах по работе с LLM. Идея проста и эффективна: заставить модель мыслить не хаотично, а внутри заданной схемы. Это не панацея, но SGR серьёзно снижает количество ошибок, делает процесс прозрачнее, а также позволяет тестировать отдельные компоненты рассуждений.
Современные экономические условия требуют от российских компаний пересмотреть подходы к ИТ-закупкам. По данным itWeek, даже при росте ИТ-бюджетов в 2025 году компании стремятся не тратить деньги впустую — прошлое десятилетие показало, как легко расходы могут выйти из-под контроля.
Компании тратят миллионы на ИТ-оборудование и лицензии, но половина активов теряется в складских остатках или дублируется по отделам. Меня зовут Евгения Асоскова, я владелец продукта SimpleOne ITAM. В статье рассказываю, как современные ITAM-системы помогают построить прозрачный и управляемый процесс закупок.
Портфель прикладных систем (Application Portfolio) - это ключевое понятие в управлении ИТ-архитектурой, описывает потребности бизнес-процессов предприятия в информационных технологиях, которые способны обеспечить автоматизированное ведение деятельности. Включает в себя набор интегрированных информационных систем. Как существующих, так и вакантных на данный момент, то есть тех, которые потребуются в будущем для обеспечения новых потребностей бизнеса и деятельности организации.
Таким образом он позволяет определить актуальный уровень покрытия необходимой функциональности бизнес-архитектуры, цифровыми решениями. А также устанавливает ответственность и приоритетность каждого приложения и варианты достижения результата, посредством либо разработки системы, либо приобретения готовых приложений, учитывая интеграцию и использование возможностей уже имеющихся ИС.
Рассмотрим эффект применения этого инструмента с разных ракурсов.
С точки зрения установления актуального состояния архитектуры, портфель описывает текущее положение компенсированности бизнес процессов предприятия - цифровыми решениями.
С точки зрения стратегии развития архитектуры, портфель презентует набор целевых прикладных систем, которые должны в перспективе удовлетворять потребности бизнес-процессов предприятия.
С точки же зрения процесса реализации планов развития, под портфелем понимается совокупность проектов, выполняемых на общем пуле ресурсов предприятия (финансы, люди, оборудование, материалы, энергия и прочее), направленных на трансформацию бизнес-процессов организации путем внедрения их цифровых двойников.
Когда в вашем ИТ-ландшафте есть «маленькая шлюпка», представляющая собой один контейнер, — это понятная и легко управляемая история. Если же речь идет о «Титанике», множестве контейнеров, то все уже не так просто, как хотелось бы. Когда же вы вырастаете до целой флотилии, где каждый корабль — это отдельный кластер Kubernetes, то здесь возникают нюансы.
В статье я поделюсь опытом, как подойти к этой проблеме системно: внедрить DevOps as a Service так, чтобы он стал не «еще одной модной практикой», а реально работающим сервисом внутри enterprise. Разберем, какие сложности чаще всего встречаются на пути, какие метрики помогают понять, что вы движетесь правильно, и как справляться с сопротивлением команд.
Музыканты - ребята творческие. И называют они себя и свои произведения тоже творчески. Иногда так заковыристо, что программистам стримингов и музыкальных сервисов остается только посочувствовать.
Вот, казалось бы, что может быть проще: создать базу треков и исполнителей. Пишем имя артиста/группы, название альбома, список треков и даем возможность по ним искать. Но потом натыкаемся на исполнителя Prince, который изменил своё имя на знак, который не существует и начинаем печалиться, потому что непонятно, как его искать после переименования. Фанаты вроде как нашли выход и предложили использовать 4 спец.символа юникода Ƭ̵̬̊, что тоже похоже на костыль, а задавать старое имя как псевдоним, вроде как концептуально неправильно. Ну или попадаются металлюги Brouillard, у которых каждый альбом называется так же - Brouillard. А каждый трек внутри альбома имеет такое же название.
Но это еще цветочки, потому дальше тесты целостности библиотеки начинают падать, так как в ней попадаются треки длиной либо одну секунду, либо 639 часов. Ну или встречаются треки с нулевым номером, потому что это так называе "секретные" композиции, которые можно было найти включением первого трека и переключением плеера назад. Как вы понимаете, сегодня мы поговорим о музыкальных edge-случаях. Заходите, будет интересно.
Криптографическая уязвимость Evolution Marketplace: Анализ кражи Исследование безопасности ECDSA подписей крупнейшего даркнет-рынка
В предыдущей части мы обсудили общие аспекты ИТ Архитектуры, и подробно затронули такой ее слой, как архитектура Данных, которая охватывает все многообразие бизнес-информации предприятия, знания о потоках ее распределения, сборе, обработке и использовании, представляемой в виде различных моделей данных.
Теперь обратимся к слою Приложений, который соотнесет используемые данные и правила их обработки с компьютерными программами, для их хранения, получения и преобразования в ходе автоматизированного выполнения бизнес-процессов.
Архитектура прикладных решений (ESA –Enterprise Solution Architecture) — это организационный дизайн всего программного приложения, включая все подкомпоненты и внешние приложения, интерфейсы для их взаимодействия, а также их поведения в рамках сотрудничества структурных элементов.
Используются этот инструмент для описания модели того, как приложение будет обеспечивать жизненный цикл необходимых бизнес-процессов, соответствующих бизнес-архитектуре предприятия. Архитектура приложений покрывает достаточно широкую область, начиная с идентификации прикладных систем необходимых предприятию для выполнения бизнес-процессов, и захватывает такие аспекты, как проектирование, разработку (или приобретение) и интеграцию прикладных систем в комплексные решения.
Потому для упрощения восприятия, как правило, разделяют две основные области ее применимости:
Помню, как на собеседовании в одну крупную компанию мне задали вопрос: "Чем отличается observability от monitoring?" Я уверенно ответил что-то про "три столпа" и "unknown unknowns". Интервьюер кивнул, но потом спросил: "А зачем платить $100k в год за Datadog, если можно поставить бесплатный Prometheus?"
Тогда я не смог внятно ответить. Сейчас, спустя три года и несколько миграций между системами мониторинга, я знаю ответ. И он стоил нашей компании около полумиллиона долларов в экспериментах. Давайте разберемся, за что же мы платим такие деньги.
Знаете, что я делал вчера с 10 до 12 утра? Деплоил новую версию на production. Вручную. На 15 серверов. По SSH. В 2024 году. И это не самое грустное. Самое грустное — что я делаю это каждую неделю. И каждый раз обещаю себе, что вот на следующей неделе точно автоматизирую. Но следующая неделя наступает, и я снова сижу и копипащу команды в терминал.
Если вы узнали себя — добро пожаловать в клуб анонимных toil-оголиков. Давайте поговорим о том, почему мы все еще делаем руками то, что должны были автоматизировать еще вчера.
Представьте, что сегодня у вас по плану тренировка с базовым упражнением — становой тягой. Вы поднимаете штангу весом в 100 кг — это ваша физическая способность на текущий цикл. Реализовать её помогают мышцы, кости связки. Вы не видите эти органы под кожей, но именно их слаженная работа позволяет вам поднять этот вес. И если бы в момент выполнения упражнения можно было просветить «рентгеном» ваш организм, их системную работу стало бы видно. А ещё стало бы понятно, на что обратить внимание для восстановления и развития, если в процессе у вас что-то «заболело».
Вы когда-нибудь видели в консоли сообщение вроде: «Access to fetch at '…' from origin '…' has been blocked by CORS policy»? Это как в том фильме: «Суслика видишь? — А он есть». CORS не бросается в глаза, пока все работает, но в нужный момент пресекает недопустимые действия. Например, чтение ответа на кросс-запрос без разрешения сервера.
Меня зовут Баир, я разработчик в команде fuse8. В этой статье я отвечу на вопросы о том, зачем была создана CORS политика, как она устроена под капотом, почему простого действия типа «поставить заголовок на бэке» может быть мало, и какие безопасные паттерны стоит выбирать во фронтенде.
Мы регулярно рассказываем о новых стандартах, протоколах и сетевых технологиях. Одну такую технологию как раз развивает рабочая группа IETF. Речь о стеке протоколов для передачи мультимедиа поверх QUIC — Media over QUIC (MoQ).
Разработка началась еще в 2022 году, однако сегодня проект получает новую порцию внимания на ИТ-площадках. Также о Media over QUIC говорят облачные провайдеры и региональные интернет-регистраторы, участвующие в развитии протокола.
Git — жизненно важный инструмент для любого разработчика.
Понимание, как работает Git, и какие возможности он даёт, позволит вам не только быстро влиться в проект, но и ничего там не испортить...
В нашей сегодняшней статье мы в деталях расскажем вам об устройстве Git, его основных командах и почему Git занял лидирующее место среди всех систем контроля версий.
Привет, Хабр!
В начале октября на XIV Международной IT-конференции «Стачка» в Санкт-Петербурге — одном из крупнейших профессиональных событий российского IT-комьюнити — мы решили провести эксперимент. Что, если предложить разработчикам публично выбрать сторону в вечных холиварах? Например: Микросервисы или монолиты? Low-code или только ручной код?
В предыдущих частях курса мы погрузились в масштабность общего восприятия архитектуры в рамках предприятия. Прошли слой Бизнес-архитектуры, рассуждая о работе организаций в терминах бизнес-моделей, бизнес-процессов, потоков ценностей и способностей бизнеса, организационной структуры и прочего.
Эти знания уже сами по себе чрезвычайно важны, для организации максимально эффективного функционирования предприятия, даже без учета ИТ составляющей. Но поскольку основная цель нашего курса — это все же развитие ИТ технологий, то с этой позиции представление Бизнес-архитектуры, служит отправной точкой на пути создания ИТ решений, которым предопределено поддерживать и развивать деловые активности предприятия. Так шаг за шагом, мы поднялись на горизонт ИТ-архитектуры.
Перед тем как приступить к рассмотрению Слоя информации, давайте все же кратко еще раз остановимся на рассмотрении общего восприятия аспектов ИТ-архитектуры.
ИТ-архитектура предприятия (Enterprise IT Architecture) — это системное представление структуры, компонентов и взаимодействий всех информационных технологий, которые поддерживают бизнес-процессы, ценности и стратегию организации. Иными словами — это “скелет” технологической среды, который обеспечивает реализацию бизнес-архитектуры и поддержку бизнес-способностей.
Из определения следует, что ИТ-архитектура, является неразделимой частью Архитектуры предприятия, всецело зависит от той мисси, которую в данной организации предопределили для информационных систем. В связи с этим она может фокусироваться на разных подходах к решению и быть:
Прежде чем приступить к готовке настоящей Системы управления информационной безопасности (СУИБ) по ISO/IEC 27001:2022, важно осознать масштаб: у нас в хозяйстве Яндекс 360 множество сервисов с уникальным вкусом и историей, каждый из которых требует бережного подхода и особой организации защиты.
Стандартизация для нас — способ не «пересолить» сложность и хаос: и мы выбрали ISO как универсальное мерило баланса. Наш главный секрет: процессы изначально проектируются по стандарту ISO, а по мере расширения области действия сертификации новые сервисы — Диск, Мессенджер, Телемост, Календарь — поступают на общий дегустационный стол сертификации и достойно занимают своё место в большом ИБ‑меню.
Меня зовут Люзия Алфёрова, я консультант по информационной безопасности в Яндекс 360. В этой статье я поделюсь проверенными приёмами, которые помогают нашей команде выдерживать технологический процесс так, чтобы ни одна деталь не была упущена, ничего не сбежало и не пригорело, а информационная безопасность получалась стабильно высокого качества.
Привет, Хабр!
«Давайте все будем на ассемблере писать. Зачем мы пользуемся фреймворками?» — эта фраза из недавней дискуссии о low-code платформах прозвучала как манифест. И она заставила задуматься: где граница между разумным использованием абстракций и откровенным vendor lock-in?
Коллеги устроили жёсткий разбор low-code платформ — без маркетингового глянца и дипломатии. Спойлер: никакой «серебряной пули» мы не нашли. Зато выяснилось, что low-code платформы прошлого и нового поколения — это принципиально разные вещи. И что конфликт между разработчиками и визуальным программированием — это на самом деле спор о том, как писать код в 2025 году, когда есть и мощные LLM, и микросервисная архитектура из сотен сервисов.
Когда тест проходит с первого раза — это пугает. Стоицизм в TDD — не методология, а форма выживания.
Человеческий мозг эволюционировал для выживания в саванне, а не для анализа распределенных систем. Когда что-то идет не так, наш древний мозг кричит: "Найди угрозу! Накажи виновного! Защити племя!" Эта реакция спасала наших предков от саблезубых тигров, но разрушает современные инженерные команды.
