1. Введение

Цифровая трансформация строительной отрасли и сферы управления недвижимостью привела к широкому внедрению технологий информационного моделирования. Если изначально технологии BIM применялись преимущественно на этапах проектирования и строительства, то сегодня наблюдается устойчивый тренд на использование информационных моделей (ИМ) на протяжении всего жизненного цикла объекта, ключевым и наиболее продолжительным этапом которого является эксплуатация. Облачные BIM-сервисы становятся основной средой для хранения и обработки данных об объекте, обеспечивая удаленный доступ всем участникам процесса: эксплуатирующим организациям, собственникам, подрядным службам, надзорным органам.

На этапе эксплуатации в облачной среде накапливаются значительные массивы данных, имеющих высокую коммерческую ценность и критическую значимость. Это не только сама информационная модель, отражающая текущее состояние здания, но и потоковые данные с датчиков Интернета вещей (IoT) о параметрах микроклимата, работе инженерных систем, показаниях счетчиков, а также юридически значимые документы: акты, договоры, отчеты об осмотрах и персональные данные арендаторов или жильцов. Проблема обеспечения безопасности этих данных становится первостепенной. Утечка или компрометация эксплуатационной информации несет в себе риски не только финансовых потерь, но и угрозы физической безопасности объекта. Несанкционированный вход в учетные записи облачных продуктов и заражение инфраструктуры программами-вымогателями являются практически значимыми сценариями угроз для организаций строительного профиля [5]. Требования российских регуляторов, в частности Федерального закона № 152-ФЗ «О персональных данных», обязывают операторов обеспечивать установленный уровень защиты обрабатываемой информации [1], [13].

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

2. Методы и принципы исследования

Теоретико-методологическую основу исследования составили научные труды отечественных и зарубежных авторов в области защиты информации, облачных вычислений и технологий информационного моделирования, нормативные документы по защите персональных данных и критической информационной инфраструктуры, а также аналитические материалы отраслевых организаций по вопросам кибербезопасности в строительстве и сфере ЖКХ. Эмпирическую базу работы сформировали техническая документация и руководства по безопасности коммерческих облачных BIM-платформ, рекомендации по управлению криптографическими ключами и мобильными устройствами, а также открытые данные о киберинцидентах в отраслевых информационных системах. В процессе исследования применялись общенаучные методы: системный анализ для структурирования классов данных и угроз на этапе эксплуатации; сравнительный анализ для сопоставления методов защиты и архитектурных решений; метод классификации и типологизации для упорядочивания мер безопасности; метод анализа случаев для оценки последствий реальных инцидентов; а также метод моделирования при описании типовой архитектуры защищенной облачной среды. Кроме того, использовались методы декомпозиции и синтеза при рассмотрении комплексной системы обеспечения безопасности как совокупности взаимосвязанных компонентов.

3. Основные результаты

Как отмечают Гришина Н. М., Мицко Д. И., этап эксплуатации здания коренным образом отличается от этапов проектирования и строительства с точки зрения характера работы с данными и требований к их защите. Если на ранних этапах жизненного цикла информация имеет проектный, часто статичный характер, то эксплуатация порождает непрерывный поток операционных и ретроспективных данных [2].

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

В-третьих, эксплуатационная информационная модель (ЭИМ) является динамической структурой. Она объединяет несколько классов данных, каждый из которых имеет свою критичность:

- базовая ИМ (архитектурные, конструктивные решения);

- данные мониторинга (телеметрия с IoT-датчиков, SCADA-систем);

- эксплуатационная документация (журналы осмотров, акты выполненных работ, паспорта систем);

- персональные данные (жильцов, арендаторов, сотрудников).

Исходя из этого, требования к безопасности на этапе эксплуатации формулируются в классической триаде CIA (конфиденциальность, целостность, доступность), но с определенными акцентами. Конфиденциальность необходима для защиты персональных данных и коммерческой информации. Целостность критически важна для ИМ и документов, так как внесение несанкционированных изменений в модель может привести к аварийным ситуациям при проведении ремонтных работ. Доступность означает, что сервис и данные должны быть доступны уполномоченным лицам в любое время для обеспечения непрерывного функционирования объекта. Дополнительным требованием является аудируемость — возможность точно определить, кто, когда и какие изменения внес в модель или данные [3].

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

Как верно подчеркивает Сафонов В. А., высокая ротация персонала и привлечение множества подрядных организаций порождают угрозы, связанные с человеческим фактором и инсайдерами. Бывшие сотрудники или недобросовестные подрядчики могут сохранить доступ к системе, если не настроены своевременная блокировка учетных записей и строгий контроль сессий. Особую опасность представляют атаки на каналы интеграции с внешними системами, такими как SCADA или «умные» счетчики. Скомпрометированный датчик или контроллер может стать точкой входа для злоумышленника во всю облачную инфраструктуру. Также актуальны атаки типа «отказ в обслуживании» (DDoS), способные нарушить работу диспетчерской службы. Программы-вымогатели, шифрующие базы договоров или архивы ИМ, могут остановить операционную деятельность эксплуатирующей организации [5].

Практическую реализуемость этих угроз показывают два типовых сценария. В первом случае злоумышленник использует ранее скомпрометированные реквизиты доступа для входа в учетную запись пользователя, не защищенную многофакторной аутентификацией. Полученные права позволяют просматривать или выгружать эксплуатационные документы и фрагменты информационной модели. Во втором случае программа-вымогатель проникает в инфраструктуру через унаследованную систему или рабочее место подрядчика, после чего шифрует цифровую документацию и пытается скопировать ее во внешнее хранилище. Эти сценарии показывают необходимость одновременно обеспечивать доступность и конфиденциальность данных с помощью MFA, контроля массовой выгрузки и изолированных резервных копий [5].

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

Базовым уровнем защиты является надежная идентификация и аутентификация пользователей. В современных облачных BIM-решениях стандартом становится применение единой системы входа (SSO — Single Sign-On), что позволяет централизованно управлять жизненным циклом учетных записей и интегрироваться с корпоративными каталогами (например, Active Directory). Обязательным требованием является использование многофакторной аутентификации (MFA), которая существенно снижает риск компрометации учетной записи даже при утечке пароля.

Управление доступом к данным реализуется на основе ролевых моделей (RBAC — Role-Based Access Control) или моделей, учитывающих атрибуты (ABAC — Attribute-Based Access Control). В контексте BIM это означает разграничение прав не только на уровне разделов или папок проекта, но и на уровне отдельных элементов модели или даже их свойств. Например, подрядчик, выполняющий ремонт в конкретном помещении, может получить доступ к элементам модели только этого помещения и только на чтение, без права редактирования остальной части здания. Разграничение по типам операций (чтение, создание, изменение, удаление, утверждение) позволяет реализовать принцип минимальных привилегий [6], [7].

Защита данных при хранении и передаче обеспечивается криптографическими методами. Критически важные данные, включая файлы ИМ и базы данных, должны храниться в зашифрованном виде с использованием стойких алгоритмов, например AES-256, либо сертифицированных средств криптографической защиты, когда их применение предусмотрено моделью угроз и требованиями регуляторов. Передача данных между клиентом и сервером защищается актуальными версиями протокола TLS, гарантирующими конфиденциальность и целостность трафика.

В мультитенантной среде криптографическая изоляция должна дополнять логическое разделение данных. Для каждого тенанта целесообразно назначать отдельный ключ шифрования ключей (Key Encryption Key, KEK), защищенный в KMS или аппаратном модуле HSM. Данные шифруются одноразовыми или регулярно обновляемыми ключами данных (Data Encryption Key, DEK), а сами DEK хранятся только в зашифрованном виде, что соответствует принципу конвертного шифрования. При модели, управляемой провайдером, генерация, хранение и ротация корневых ключей находятся в зоне ответственности поставщика облачного сервиса. Модель Bring Your Own Key (BYOK) передает заказчику контроль над ключом тенанта: заказчик создает или импортирует его, устанавливает сроки ротации, получает независимый журнал операций и может отозвать доступ. BYOK повышает контролируемость обработки и поддерживает требования к суверенитету данных, но не освобождает оператора и провайдера от договорного закрепления ответственности за доступность KMS, резервирование ключей и восстановление после их утраты. Политика управления ключами должна охватывать генерацию, выдачу прав, ротацию, отзыв, архивирование и уничтожение ключевого материала [7].

Для обеспечения целостности информации необходимы механизмы контроля версий и журналирования изменений. Каждое изменение в ИМ должно фиксироваться как отдельная версия с возможностью возврата к предыдущему состоянию, что защищает от случайных или злонамеренных правок. Для юридически значимых документов (акты, договоры) рекомендуется применение хеширования или усиленной квалифицированной электронной подписи, что гарантирует их подлинность и неизменность. Аудит и мониторинг являются активными методами защиты. Система должна в автоматическом режиме собирать и анализировать события доступа и изменения данных. Выявление аномалий (например, массовая выгрузка документов или вход в систему в нерабочее время) позволяет оперативно реагировать на потенциальные инциденты. Наконец, политики резервного копирования и восстановления приобретают на этапе эксплуатации критическое значение. Регулярное создание резервных копий, их хранение в географически распределенных центрах обработки данных и, что самое важное, регулярное тестирование восстановления из «бэкапов» являются последней линией обороны против потери данных, в том числе вследствие атак программ-вымогателей [8].

Архитектура безопасности облачного BIM-сервиса строится по эшелонированному принципу. На внешнем контуре клиентские приложения взаимодействуют с системой через защищенный API-шлюз, обеспечивающий терминацию TLS-соединений и первичную фильтрацию трафика. Уровень сервисов приложения разделяется на внешний контур (DMZ), обрабатывающий запросы, и внутренний, где размещаются изолированные микросервисы безопасности: аутентификация, аудит и управление ключами. Такое разделение минимизирует поверхность атаки. В многопользовательской архитектуре критически важна изоляция тенантов на уровне баз данных, файловых хранилищ и криптографических ключей. Специфика эксплуатационных данных требует дифференцированного подхода к хранению: высоконагруженные потоки телеметрии обрабатываются через очереди сообщений и базы временных рядов, тогда как документооборот и информационная модель размещаются в объектных хранилищах с поддержкой версионности. Доступ к хранилищам строго соответствует ролевой модели приложения [10].

Отдельной точкой внешнего контура являются мобильные клиенты, используемые техническим персоналом при осмотрах и ремонте. Их доступ следует разрешать только с зарегистрированных устройств, соответствующих корпоративной политике безопасности. Средства MDM или EMM должны обеспечивать шифрование локального хранилища, разделение служебных и личных данных, контроль версий операционной системы, запрет небезопасного копирования и удаленное стирание служебного контейнера. Локальное кэширование фрагментов ИМ ограничивается сроком и объемом, а особо критичные операции подтверждаются повторной аутентификацией. При утрате устройства токены и сертификаты доступа должны быть немедленно отозваны; весь обмен выполняется по защищенному каналу и регистрируется в журнале аудита [7].

4. Обсуждение

Выбор модели использования облачной инфраструктуры определяется требованиями к суверенитету данных. Зарубежные платформы (Autodesk BIM 360) строятся на публичной облачной инфраструктуре, тогда как российские разработчики (АСКОН, G Tech) предлагают решения в защищенных контурах или частных облаках, ориентированные на исполнение требований законодательства РФ. При этом географическое размещение данных, юрисдикция провайдера и местонахождение ключевого материала должны оцениваться раздельно. Применение BYOK позволяет усилить контроль заказчика над доступом к данным, однако само по себе не заменяет требований к локализации, сертификации средств защиты и договорному распределению ответственности.

Новоселова И.В., Чернявский И.А. пишут о том, что выбор методов защиты должен основываться на анализе рисков конкретного объекта [11]. Для небольшого объекта, не отнесенного к значимым объектам критической информационной инфраструктуры (КИИ), минимальный набор включает SSO с MFA, ролевой доступ, шифрование данных при хранении и передаче, централизованный аудит и управляемые мобильные клиенты. Практически обоснованной отправной точкой является ежедневное инкрементное и еженедельное полное резервное копирование с одной изолированной неизменяемой копией; целевые значения допустимой потери данных (RPO) до 24 часов и времени восстановления (RTO) до 8 часов уточняются по результатам анализа влияния на деятельность. Восстановление необходимо проверять не реже одного раза в квартал.

Для средних и крупных объектов рекомендуются отдельные ключи тенантов, сегментация сети, централизованный сбор событий безопасности, резервирование KMS и сокращение RPO и RTO в соответствии с критичностью инженерных процессов. Унаследованные системы не следует подключать непосредственно к облачному хранилищу: их интеграция выполняется через выделенный шлюз в сегменте DMZ с инвентаризацией интерфейсов, фильтрацией команд, преобразованием устаревших протоколов и, где это возможно, доступом только на чтение. Для объектов, подпадающих под действие Федерального закона № 187-ФЗ, проводится категорирование и реализуются меры защиты, соответствующие значимости объекта [14]. При обработке персональных данных состав мер определяется с учетом требований Федерального закона № 152-ФЗ [13]. Для стратегических и иных высококритичных объектов необходима полноценная система с сегментированием сети, HSM, SIEM, изолированными контурами резервного копирования и непрерывным контролем каналов интеграции.

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

5. Заключение

Таким образом, обеспечение безопасности данных в облачных BIM-сервисах на этапе эксплуатации является сложной многогранной задачей. Специфика этапа — длительный жизненный цикл, множество разнородных участников, высокая ценность и разнообразие данных — требует применения комплексного подхода к защите. Такой подход должен сочетать надежную идентификацию и управление доступом на гранулярном уровне, криптографическую защиту с разделением ключей тенантов и определенной моделью ответственности за KMS, обеспечение целостности через контроль версий и аудит, защиту мобильных клиентов, а также отказоустойчивую архитектуру хранения и резервного копирования. Архитектура современного защищенного BIM-сервиса строится по эшелонированному принципу с выделением контуров безопасности, логической и криптографической изоляцией тенантов и интеграцией с инфраструктурными сервисами облачных провайдеров. Состав мер должен определяться анализом рисков, чувствительностью данных и применимыми требованиями регуляторов, а их эффективность — подтверждаться проверками восстановления и анализом событий безопасности. Реализация этих принципов позволяет минимизировать риски утечек, нарушения целостности и потери данных. Практическая значимость работы заключается в создании основы для выбора и внедрения адекватных мер защиты при переходе к облачным технологиям управления эксплуатацией.

The additional file for this article can be found as follows: