Журнал "Information Security/ Информационная безопасность" #4, 2026

пытаться компенсировать ограничения систем, которые сложно обновлять и патчить. Дмитрий Архипов, "Айсорс" Это не столько дилемма, сколько реальность, в которой унаследованные и новые системы существуют одновре- менно и тесно взаимодействуют. Для унаследованных систем ключевыми остаются учет, контроль изолированно- сти, ограничение внешних соединений и удаленного доступа, а также регуляр- ная проверка возможности восстанов- ления. Для новых решений Secure by Design должен быть обязательным тре- бованием уже на этапе проектирования архитектуры и закупки. Это означает поддержку безопасного обновления, журналирование, разграничение полно- мочий, резервное восстановление и управление учетными данными. Особое внимание требуется на стыке старых и новых систем – например, при передаче данных. Здесь проектируются интеграционные шлюзы, односторонние каналы связи, механизмы безопасной передачи данных и каскады проверок. Наиболее эффективный подход – не решать такие задачи отдельно в каждом проекте, а оформлять их в единые архи- тектурные принципы и практики. Артем Яковлев, "Газпром ЦПС" Наша команда разработки при про- ектировании новых систем и сред раз- работки и тестирования использует под- ход Secure by Design и Shift Left, то есть мы переносим вопросы информационной безопасности на максимально ранние этапы жизненного цикла разработки. Безопасность должна начинаться уже с момента подготовки исходного кода. В процесс разработки встраиваются инструменты анализа кода, поиска уязвимостей и другие средства контроля. Разработчик получает информацию о проблемах непосредственно на этапе написания кода, а на тестирование дол- жен поступать код, уже прошедший необходимые проверки безопасности. Таким образом формируется DevSec- Ops-подход, при котором контроль без- опасности встроен в каждый этап жиз- ненного цикла разработки: от создания кода до тестирования, подготовки к выпуску и вывода в продуктив. Для уна- следованных систем при этом прихо- дится сочетать такие подходы с посте- пенным усилением существующих средств защиты. Не всегда возможно сразу перестроить архитектуру, поэтому важно последовательно снижать риски, сохраняя работоспособность уже суще- ствующей инфраструктуры. В результате безопасность становится не финальным контролем перед выпуском, а неотъем- лемой частью процесса разработки, что одновременно повышает качество про- дукта и снижает количество итераций исправлений на финальных этапах. Артем Яковлев, "Газпром ЦПС" Из наиболее показательных для нашей команды инцидентов я бы выделил взлом крупной платформы для разме- щения сайтов компании 4 года назад, который оказал влияние не только на команду разработки, но и на подходы компании в целом. Ключевая проблема заключалась не столько в отсутствии средств защиты самой площадки, сколь- ко в организации процесса разработки: разработчики работали на своих рабочих станциях и имели возможность напря- мую размещать код на внешней пло- щадке. Такой подход создавал допол- нительные риски, которые в конечном итоге реализовались в виде инцидента. Основной вывод заключался в том, что даже хорошо защищенная внешняя пло- щадка не может считаться безопасной, если компания не контролирует весь цикл разработки и размещения про- граммного обеспечения. После этого подход был пересмотрен: полный цикл разработки – от среды разработки и тестирования до препрода и продуктивной среды – был перенесен в контролируемый контур компании. Код проходит необходимые проверки без- опасности до попадания в продуктив. При этом продуктивные системы должны размещаться в средах, которые компа- ния способна контролировать: подклю- чать к ним средства защиты, собирать логи и своевременно реагировать на инциденты. Главный урок – безопасность должна обеспечиваться не только на уровне конечной площадки, но и на всем жизненном цикле разработки и экс- плуатации системы. Алексей Диянов, Nedra Digital Из публично описанных случаев для российского нефтегаза наиболее пока- зателен инцидент с TetraSoft в 2024 г. Компания обеспечивает удаленный мониторинг добычи углеводородов. По данным Positive Technologies, проникно- вение произошло в июле, активные дей- ствия – в конце сентября – начале октяб- ря. Это была атака на цепочку поставок с прицелом на заказчиков. Исполни- тельный директор TetraSoft оценивал ее как первую за несколько лет, нацелен- ную на максимальный отраслевой урон отечественной добыче. В публикациях называли оценку ущерба порядка 100 млн руб. Влияние на промыслы, по заявлениям участников расследования, удалось купировать. Урок очевиден: целью часто становятся не вертикально интегрированные нефтегазовые компа- нии, а подрядчики с доступом к теле- метрии и контурам заказчика. Между входом и действиями – месяцы тишины. Это сдвигает приоритеты с периметра самой добывающей компании на инвен- таризацию вендоров, контроль их уда- ленного доступа и способность отклю- чить сервис мониторинга, не остановив скважину. Именно поэтому в отрасли стали жест- че смотреть на любой внешний контур вокруг промысла: техподдержка, облач- ный архив технологической телеметрии, удобный удаленный доступ инженера подрядчика. По последствиям компро- метация внешней инфраструктуры может быть сопоставима с компромета- цией собственной – это и есть то, что меняет подход, а не еще один чек-лист по паролям. Дмитрий Архипов, "Айсорс" В СМИ мне попадался случай атаки на систему распределения топлива в Иране в 2023 г., она нарушила работу сети автозаправочных станций. Вектор атаки был направлен на систему обслу- живания и оплаты, но в результате про- изошло масштабное нарушение физи- ческого отпуска топлива. По сути, вспо- могательный централизованный цифро- вой сервис может превратиться в единую точку отказа для всей цепочки сбыта, а при некоторых условиях и производ- ства. То есть системы идентификации, расчетов, диспетчеризации, управления доступом к продукции – тоже должны входить в периметр применения прин- ципа Secure by Design. Алексей Диянов, Nedra Digital Это, конечно, вопросы не про выбор антивируса, а про допустимый простой и допустимый поток данных. ИБ хочет изоляцию и патчи по расписанию. АСУ ТП требует непрерывности: контроллер не перезагружают в смену, на опера- торских станциях до сих пор встре- чаются общие учетные записи, потому что смена – это роль, а не персона. ИТ хочет шину данных, API и двойника в реальном времени. На этом стыке проекты и встают. Второй конфликт – классификация. Геология, сейсмика, геолого-техниче- ские мероприятия, телеметрия скважины и модель цифрового двойника могут быть коммерческой тайной, сведениями о недрах или контуром, который заказчик относит к КИИ. Пока три службы не зафиксировали, какие данные и куда Какой киберинцидент в нефтегазовой отрасли последних 2–3 лет оказал наибольшее влияние на изменение подходов к защите – и чему он научил индустрию? В каких вопросах ИТ, ИБ и АСУ ТП, по вашему опыту, сложнее всего догово- риться при реализации цифровых проектов в нефтегазе? • 75 БЕЗОПАСНАЯ РАЗРАБОТКА www.itsec.ru