Крупная нефтяная компания (название — под NDA) реализует строительство объектов в рамках освоения нефтяных месторождений. Для эффективного управления проектами компания приняла решение оцифровать строительный контроль и исполнительную документацию с помощью платформы ЦУС.
Перед внедрением ЦУС заказчик провел аудит на информационную безопасность строительного ПО (ИБ) — инструментальные проверки системы на уязвимости для поставки в закрытый ИТ-контур. За 3 месяца проверок команда разработки ЦУС:
- прошла аудит кода, контейнерной сборки и инфраструктурных компонентов;
- устранила уязвимости, выявленные инструментами заказчика;
- переработала архитектуру контейнерной поставки и структуру пакетов;
- внедрила безопасное хранение секретов и усилила механизмы защиты данных.
В результате платформа ЦУС подтвердила соответствие требованиям ИБ, что обеспечило информационную безопасность корпоративных систем — компания внедрила ЦУС в свою инфраструктуру и масштабировала ПО на другие строительные процессы.
Контекст и задачи
Инфраструктура заказчика работает в закрытом контуре — корпоративной среде, изолированной от любых внешних ресурсов. Это позволяет защитить производственные, управленческие системы от кибератак, утечек данных и внешнего вмешательства, а также поддерживать требуемый уровень безопасности корпоративных систем.
ЦУС требовалось развернуть в формате On-Premise на серверах компании. Как и любая система, которая размещается внутри контура, ЦУС должна была пройти процедуры информационной безопасности в строительстве по утвержденным регламентам. Перед разработчиками стояли три ключевые задачи:
1. Подтвердить соответствие платформы требованиям информационной безопасности.
2. Устранить все уязвимости, выявленные в ходе проверок.
3. Доказать отсутствие критических уязвимостей в коде, архитектуре и используемых компонентах.
Проверки затронули всю систему целиком: исходный код, архитектуру приложения, контейнеры, системные пакеты, сторонние библиотеки и зависимости.
Ключевые термины статьи
Безопасность корпоративных систем — это состояние и совокупность организационных, правовых и технических мер, обеспечивающих защиту информационных систем, бизнес-процессов, сотрудников, активов и данных компании от внутренних и внешних угроз с целью сохранения устойчивости, непрерывности и управляемости деятельности организации.
Одним из механизмов обеспечения безопасности корпоративных систем является обязательная проверка любого внедряемого программного обеспечения на соответствие требованиям информационной безопасности компании.
Информационная безопасность в строительстве — это обеспечение конфиденциальности, целостности и доступности цифровых данных в информационных системах (ИС) на всех этапах строительного проекта.
К таким данным относятся: проектная и исполнительная документация, финансовая информация, модели объектов, персональные данные и переписка участников строительства. Среди информационных системов могут быть сайты, облачные платформы, корпоративные порталы, СЭД, CRM, почта и другие ИС, через которые сотрудники работают с корпоративными данными.
Проверка системы на уязвимости — это процесс выявления уязвимостей программного обеспечения, которые могут быть использованы для реализации киберугроз, выполняемый с помощью автоматизированных сканеров и/или ручных методов анализа с формированием отчета и рекомендаций по устранению обнаруженных уязвимостей.
Далее подробно расскажем, как ПО проходит проверки на уязвимости на примере кейса нефтяной компании.
Читайте еще больше кейсов цифровизации в нашей рассылке
Как 7 заказчиков оцифровали стройку
Платформа прошла три типа проверок системы на уязвимости
Каждая проверка проводится с помощью специализированных инструментов. Они анализируют систему по собственным критериям, установленным заказчиком.
Пакетная проверка контейнеров. ЦУС поставляется контейнерным способом, который позволяет легко перенести, развернуть и проверить приложение в любой среде. Благодаря данному способу разработчики ЦУС и системного интегратора смогли быстро и стабильно выстроить процессы передачи и проверки компонентов ПО, работая в разных средах.
Проверки проходили с помощью сканера безопасности Trivy. Контейнер сам по себе — это сложная структура, которая содержит в себе операционную систему и специальные механизмы. Поэтому анализировались как компоненты контейнера, так и их содержимое:
- используемая операционная система,
- системные пакеты,
- библиотеки и зависимости,
- структура контейнерной сборки.
Поставка выстраивалась итеративно. Команда ЦУС формировала контейнерную сборку и передавала ее в заранее подготовленное защищенное пространство — виртуальную комнату для обмена файлами. Оттуда специалисты интегратора забирали контейнеры, проводили инструментальные проверки системы на уязвимости и возвращали сборку с замечаниями. Итерации проходили до тех пор, пока количество замечаний не снизилось до уровня, позволяющего пройти требования информационной безопасности в строительстве и защитить корпоративные системы заказчика.
Проверка кода методом SAST. Данный метод позволяет проверить исходный код на уязвимости еще до запуска ПО ЦУС. Так инструмент Defect Dojo анализировал систему на неправильную обработку данных, SQL-инъекции, XSS, небезопасные конструкции и устаревшие библиотеки, то есть типовые риски, напрямую влияющие на безопасность корпоративных систем.
Проверка кода на секреты. С помощью GitLeaks отдельно анализировалось наличие токенов, паролей, ключей и других чувствительных данных. Такие данные не должны храниться напрямую в коде приложения.
Иван Яценко, руководитель отдела проектной разработки
Инструменты заказчика не выявили критических уязвимостей — это часто показывает, насколько системно вендор работает с кодом. Платформа ЦУС изначально создавалась с учетом современных практик безопасной разработки. Наши архитектурные и технические решения предусматривают защиту от типовых сценариев атак, включая попытки взлома и DDoS. В рамках аудита мы дополнительно переработали ряд участков кода, исключили срабатывания инструментов проверки системы на уязвимости и тем самым еще больше повысили общий уровень защищенности системы.
Как команда ЦУС снизила уязвимости
Передала только необходимый код
Одним из первых решений стала оптимизация состава поставки системы. Заказчику требовался ограниченный функционал — модули исполнительной документации и строительного контроля. Команда ЦУС сформировала поставку, содержащую только необходимые компоненты.
Чем меньше кода, тем меньше шансов, что в нем будет уязвимость, поэтому такой подход существенно повысил безопасность платформы и корпоративных систем заказчика.
Внедрила систему безопасного хранения секретов
Ранее секреты частично хранились в конфигурационных файлах кода. С ростом требований к безопасности команда ЦУС внедрила специализированное защищенное хранилище Vault, куда были вынесены все секреты: токены, пароли и ключи. Это решение соответствует лучшим практикам безопасной разработки.
Дополнительно реализовала следующие меры:
— Контроль доступа к секретам на уровне приложения, чтобы пользователь мог работать только с теми данными, к которым у него есть права.
— Укрепление механизма валидации и санитайзинга данных, что снижает риск эксплуатации потенциальных уязвимостей через пользовательский ввод.
Результат: система ЦУС соответствует требованиям информационной безопасности в строительстве
После реорганизации контейнера, подбора пакетов и других методов программный продукт Trivy не обнаружил в них уязвимости. Проверки кода также показали отсутствие уязвимостей критического и высокого уровня, что обеспечивает полную безопасность корпоративных систем заказчика.
ЦУС успешно прошел проверки информационной безопасности и был допущен к эксплуатации у нефтяной компании. При развертывании системы инженеры DevOps помогли специалистам системного интегратора правильно ее развернуть на серверах заказчика. После внедрения при обновлении ЦУС поставка системы происходит таким же образом: сначала комплексные проверки системы на уязвимости, потом допуск к эксплуатации.
Иван Яценко, руководитель отдела проектной разработки
Этот проект стал важным шагом в развитии компетенций команды ЦУС в области поставки программного обеспечения для крупных промышленных заказчиков в закрытые инфраструктуры.
В рамках кейса мы пересмотрели ряд системных подходов: усилили механизмы валидации и санитайзинга данных, контроль взаимодействия приложения с базой данных и оптимизировали структуру контейнерной сборки. Часть доработок была связана с приведением архитектуры поставки к более строгим требованиям проверяющих инструментов.
Мы масштабируем каждый опыт прохождения проверок информационной безопасности в строительстве на все последующие проекты. Помимо того, что наш код соответствует последним требованиям сканеров, мы также автоматизируем сборку системы строго под требуемый набор модулей у каждого конкретного заказчика.
