Кибербезопасность в IT‑проектах: угрозы, риски и стандарты информационной безопасности в IT‑отрасли

Кибербезопасность в IT-проектах за последние годы перестала быть отдельной технической функцией. Для бизнеса это уже вопрос устойчивости процессов, контроля над инфраструктурой и способности компании управлять собственной цифровой средой. Главной проблемой становится не отсутствие отдельных средств защиты, а потеря прозрачности инфраструктуры, слишком высокая динамика в изменениях, процессах, большое количество данных для анализа, потенциальных рисков, повышение конкурентной среды. Расскажем подробнее в статье.

Актуальные киберугрозы для IT-проектов в 2026 году

Трансформация ландшафта угроз и новая поверхность атаки

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

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

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

Из-за этого меняется и характер атак. Если раньше злоумышленники концентрировались на сетевом периметре, сегодня основными точками входа становятся API, учетные записи, облачные сервисы и процессы CI/CD.

Например, компрометация учетной записи разработчика может привести к доступу в Git-репозиторий, затем — к CI/CD-конвейеру, после чего злоумышленник получает возможность внедрить вредоносный код в production-среду. Во многих случаях сама атака занимает значительно меньше времени, чем ее последующее обнаружение.

Еще одна проблема — рост количества сервисных аккаунтов и технических пользователей. Во многих инфраструктурах именно они становятся blind spot для ИБ-команд: доступы не пересматриваются, пароли не обновляются годами, а сами учетные записи используются сразу несколькими системами и командами.

Именно поэтому современная кибербезопасность IT-инфраструктуры постепенно уходит от модели изолированной защиты отдельных систем к задаче непрерывного контроля всей цифровой среды.

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

Контур.Эгида — сервисы информационной безопасности: уменьшение рисков внутренних угроз и утечек конфиденциальных данных, предотвращение атак злоумышленников.

Оставить заявку

Атаки на цепочки поставок ПО и сторонние компоненты

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

Проблема заключается не только в уязвимостях отдельных библиотек. Главный риск связан с потерей прозрачности разработки. Команды постоянно обновляют компоненты, CI/CD автоматически собирает зависимости, а скорость изменений не позволяет вручную контролировать всю цепочку поставок.

В результате одна уязвимая библиотека может стать точкой входа сразу для нескольких систем. Особенно опасны ситуации, когда компрометируется не вспомогательная инфраструктура разработки: Git-серверы, реестр контейнеров, системы сборки или тестовые среды.

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

В ответ компании начинают внедрять SBOM (Software Bill of Materials), автоматический анализ зависимостей и процессы постоянного контроля сторонних компонентов. По сути, речь идет о попытке вернуть контроль над средой, которая слишком быстро усложняется.

Риски использования искусственного интеллекта в разработке

Использование ИИ-инструментов в разработке стало обычной практикой. Генерация кода, автоматизация тестирования, помощники, агенты позволяют ускорять работу команд, но одновременно создают новые угрозы безопасности ПО в ИТ.

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

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

На практике это уже приводит к появлению нового типа shadow IT (теневой инфраструктуры) внутри разработки. Сотрудники, по последним данным, около 40%, начинают использовать внешние AI-инструменты без согласования с ИБ и эксплуатацией, а компания теряет понимание того, какие данные покидают внутренний контур.

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

Рост целевых атак на веб-приложения и API

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

При этом API постепенно становятся новой внутренней сетью компании. Через них проходят бизнес-операции, данные пользователей и взаимодействие между сервисами. Ошибка в логике авторизации или компрометация токена может открыть злоумышленнику доступ сразу к нескольким системам.

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

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

Угрозы, связанные с утечками данных и человеческим фактором

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

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

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

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

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

Нормативно-правовая база и стандарты информационной безопасности

Международные стандарты: ISO/IEC 27000, NIST, CIS Controls

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

ISO/IEC 27001, NIST Cybersecurity Framework и CIS Controls фактически описывают, как организация должна контролировать доступ, управлять изменениями, реагировать на инциденты и поддерживать прозрачность инфраструктуры.

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

Российские стандарты и требования регуляторов

Российские стандарты постепенно становятся более прикладными и ближе к реальным процессам разработки и эксплуатации инфраструктуры.

Например, ГОСТ Р 56939-2024 уделяет внимание безопасному жизненному циклу программного обеспечения и интеграции ИБ в процессы разработки. Это отражает общий тренд: безопасность перестает быть отдельным этапом проверки перед релизом и становится частью всего цикла разработки.

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

Основные требования сегодня формируются вокруг:

• Федерального закона №152-ФЗ «О персональных данных»;
• Федерального закона №187-ФЗ «О безопасности критической информационной инфраструктуры РФ»;
• приказов ФСТЭК;
• требований Банка России.

Приказ №117 ФСТЭК России и переход к Zero Trust

Приказ №117 ФСТЭК России, вступивший в силу с марта 2026 года, отражает изменение подходов к защите современной ИТ-инфраструктуры. Его требования во многом соответствуют принципам концепции Zero Trust, поскольку традиционная модель «доверенной внутренней сети» перестала отвечать современным условиям. Удаленная работа, облачные сервисы и распределенная инфраструктура существенно размыли классический сетевой периметр.

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

При этом организациям, которые уже внедрили процессы разработки безопасного программного обеспечения в соответствии с ГОСТ по РБПО, будет проще выполнить часть требований приказа №117. Многие практики безопасной разработки — управление уязвимостями, контроль изменений, анализ рисков и обеспечение безопасности на всех этапах жизненного цикла ПО — помогают выполнить значительную часть организационных и технических требований нового приказа. Поэтому инвестиции в РБПО сегодня не только повышают защищенность информационных систем, но и упрощают выполнение регуляторных требований.

Фактически идентификация становится новым периметром безопасности. Именно поэтому системы IAM, MFA и PAM постепенно переходят из категории дополнительных средств защиты в основу современной архитектуры информационной безопасности. При этом на первый план выходит не столько использование отдельных инструментов, сколько их совместная работа в рамках единой экосистемы, где механизмы идентификации, аутентификации и управления привилегированным доступом дополняют друг друга.

Управление рисками информационной безопасности в IT-проектах

Идентификация и анализ IT-рисков

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

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

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

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

Построение системы непрерывного мониторинга и управления уязвимостями

Современная кибербезопасность IT-инфраструктуры требует непрерывного мониторинга. Ручные проверки и периодические аудиты больше не успевают за скоростью развития инфраструктуры.

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

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

Безопасная разработка программного обеспечения и DevSecOps

Почему классический подход к безопасности разработки перестал работать

Во многих компаниях вопрос безопасности разработки и ее результатов по-прежнему поднимается только перед релизом. Разработка и ИБ при этом часто существуют как параллельные процессы: команды движутся в собственном темпе, регулярно выпускают обновления и проводят проверки безопасности отдельно друг от друга.

В современных условиях такой подход начинает создавать все больше проблем. Инфраструктура меняется слишком быстро, а количество изменений внутри CI/CD-конвейеров настолько велико, что ручной контроль безопасности перестает масштабироваться.

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

Разработка безопасного программного обеспечения предполагает, что требования безопасности учитываются не только на этапе тестирования, но на протяжении всего жизненного цикла системы. Именно такой подход позволяет своевременно выявлять и устранять потенциальные уязвимости, а также облегчает выполнение части требований приказа ФСТЭК №117.

Подход основан на требованиях российских стандартов по разработке безопасного программного обеспечения (РБПО) и отражает типовые практики обеспечения безопасности на различных этапах жизненного цикла ПО.

Аудит безопасности и тестирование на проникновение

Во многих компаниях аудит ИБ, пентест и red teaming до сих пор воспринимаются как взаимозаменяемые услуги. Но эти подходы не конкурируют друг с другом, а применяются для решения разных задач.

Аудит безопасности ИТ проектов помогает понять, насколько компания контролирует собственную инфраструктуру и где находятся организационные слабые места.

Пентест моделирует действия злоумышленника и проверяет, насколько реально эксплуатировать существующие уязвимости. При этом whitebox-, greybox- и blackbox-подходы позволяют оценивать инфраструктуру с разным уровнем исходной информации.

Red teaming идет дальше. Его задача — проверить не только возможность проникновения, но и способность компании обнаруживать атаку, расследовать инцидент и реагировать на него в реальном времени.

Оценим систему защиты в вашей компании

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

Оставить заявку

Практическая защита инфраструктуры и веб-проектов

Кибербезопасность облачных проектов

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

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

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

Безопасность ERP-систем и корпоративных приложений

После 2022 года рынок ERP-систем в России начал быстро меняться. Компании переходят на отечественные решения, перерабатывают архитектуру и перестраивают интеграции между системами.

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

По данным Anti-Malware, устаревшее ПО и уязвимые веб-приложения остаются одной из ключевых причин успешных атак на корпоративные системы.

MSS, MDR и SOC как ответ на дефицит ресурсов

Еще один заметный тренд последних лет — рост интереса к MSS- и MDR-сервисам. Причина не только в усложнении атак, но и в дефиците специалистов.

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

Поэтому компании все чаще используют смешанную модель: критичные решения и ответственность за риски остаются внутри, а мониторинг, обнаружение и первичное реагирование передаются MSS/MDR-провайдерам. Рост такого подхода виден по рынку: ENISA отмечает растущую роль управляемых сервисов безопасности, а MarketsandMarkets прогнозирует рост мирового рынка MDR с $6,28 млрд в 2026 году до $19,01 млрд к 2031 году. 

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

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

Контур.Эгида — сервисы информационной безопасности: уменьшение рисков внутренних угроз и утечек конфиденциальных данных, предотвращение атак злоумышленников.

Оставить заявку

Вместо заключения: системный подход как основа киберустойчивости IT-проектов

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

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

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

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