Autodesk Construction Cloud в закрытом контуре: проверки до пилота

Что именно проверить до пилота

Под «закрытым контуром» обычно понимают среду, где доступ к данным и сервисам жестко ограничен: работают прокси и белые списки, иногда нет прямого выхода в интернет, действуют требования по резидентности данных и обязательному аудиту действий. В таких условиях Autodesk Construction Cloud оценивают не только по удобству для команды, но и по тому, можно ли безопасно и законно встроить сервис в вашу ИТ-среду.

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

До закупок и обучения лучше заранее закрыть темы, которые потом дорого переделывать:

• Идентификация и доступ: кто и как входит, как быстро отключается доступ в день увольнения, как оформляется доступ подрядчикам.
• Данные: где физически хранятся, что с шифрованием, резервными копиями и правами на выгрузку.
• Интеграции: какие корпоративные системы нужны на старте (EDMS, почта, файловые хранилища, каталоги пользователей), что реально сделать через API, а что останется ручной процедурой.
• Журналирование: какие события пишутся, как долго хранятся, как выгружать их в SIEM и как подтверждать действия пользователей.

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

Карта требований: безопасность, регуляторика, процессы

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

Сначала соберите владельцев требований и договоритесь, что их решения финальные. Обычно нужны ИТ (сеть, учетные записи, поддержка), ИБ (политики, риски, журналирование), юристы и комплаенс (договоры, ответственность, хранение), эксплуатация (резервирование, инциденты, регламенты) и проектный офис или заказчик (как это должно работать «в поле»).

Дальше зафиксируйте классы данных. Минимально разделите:

• проектные файлы (чертежи, модели, фото),
• персональные данные (например, данные сотрудников в актах и пропусках),
• коммерческую тайну (сметы, условия договоров).

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

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

В конце определите критерии успеха пилота, чтобы потом не спорить «получилось или нет». Достаточно 4-6 критериев, например:

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

Если пилот делаете с интегратором, эту карту требований лучше утвердить до настройки тестового стенда. Так меньше переделок на ходу.

Хранение данных: резидентность, шифрование, резервные копии

Для пилота важно заранее понять, где будут лежать файлы, метаданные, комментарии и журналы. В теме Autodesk Construction Cloud в закрытом контуре резидентность часто становится стоп-фактором не из-за возможностей сервиса, а из-за требований заказчика и регуляторики.

Сначала зафиксируйте, какие типы данных вы загрузите в пилот (чертежи, модели, фото, переписка, отчеты), и сопоставьте это с требованиями по местоположению хранения. Если часть данных нельзя хранить за пределами страны или в публичном облаке, это нужно выявить до того, как первые проекты окажутся в системе.

Что подтвердить документально

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

Короткий минимум вопросов для проверки:

• В каком регионе/стране размещаются данные пилота и резервные копии.
• Какие данные шифруются и на каких этапах (передача, хранение).
• Как устроено разделение данных между проектами и командами (чтобы подрядчики не видели чужое).
• Что входит в резервное копирование со стороны сервиса, а что остается вашей зоной ответственности.
• Какие есть сроки хранения, удаление и возврат данных после пилота.

Резервные копии и выход из пилота

Проверьте сценарий восстановления: кто инициирует, сколько времени занимает, что считается успешным восстановлением (например, модель + история изменений + права доступа). Если в пилоте участвуют несколько подрядчиков, заранее договоритесь, кто выгружает финальный архив и где он хранится дальше.

Здесь часто помогает отдельная, заранее описанная схема «выгрузка - хранение - проверка целостности - доступ». Ее удобно согласовывать не на словах, а как короткий регламент: кто имеет право выгружать, где лежит «золотая» копия, кто подтверждает полноту.

Управление доступом и идентификацией

В закрытом контуре доступы - это не «галочка», а главный рычаг контроля. До пилота важно договориться, кто считается владельцем среды Autodesk Construction Cloud, кто создает проекты, кто назначает роли и как фиксируются изменения. Если администрирование размазано между ИТ, ИБ и руководителями проектов, ошибки обычно начинаются с лишних прав.

Проверьте модель ролей и групп. Удобнее, когда доступы выдаются через группы (по функциям и проектам), а не вручную каждому пользователю. Отдельно уточните, где хранится «истина»: список прав в ACC, в вашей IDM-системе или в регламенте, который никто не обновляет.

SSO, MFA и жизненный цикл аккаунта

Определите, как будет устроен вход: через корпоративный SSO или через отдельные учетные записи. В закрытом контуре почти всегда требуется MFA. Важно заранее проверить, поддерживается ли выбранный вариант в вашей среде (например, аппаратные токены или корпоративное приложение) и как это будет работать у внешних подрядчиков.

Если планируется связка с AD/LDAP, прогоните жизненный цикл пользователя: создание, смена отдела, блокировка, увольнение. Критичный вопрос - как быстро доступ пропадет в ACC после отключения учетной записи в домене.

Подрядчики и временные права

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

• выдача доступа по заявке с владельцем проекта;
• ограничение прав по ролям и сроку;
• отзыв доступа в день закрытия работ;
• смена ответственных без «зависших» админов;
• регулярная (например, ежемесячная) сверка активных пользователей и прав.

Пример: генподрядчик запускает пилот на одном объекте и подключает трех субподрядчиков. Если всем выдать роль Project Admin, они увидят лишние документы и настройки. Если дать роли по задачам (например, только просмотр и RFI) и срок на 30 дней, риск утечки и случайных изменений заметно снижается.

Если пилот идет с участием интегратора, заранее закрепите, кто администрирует доступы и кто проводит аудит прав, чтобы не зависеть от «ручных» действий одного человека.

Интеграции: приложения, API, обмен с корпоративными системами

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

Что проверить по приложениям и рабочим местам

Начните с практики: откройте типовой проект и пройдите путь от модели до замечаний. Проверьте, что ваши BIM/CAD инструменты и просмотрщики корректно публикуют и обновляют модели, не плодят лишние копии на локальных дисках, и нормально работают на слабых рабочих местах или в тонких клиентах (если они используются).

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

Дальше переходите к API и коннекторам. Сформулируйте список систем, которые вы хотите связать: документооборот, ERP, Service Desk, хранилище архивов, корпоративный каталог пользователей. Важно описать поток данных: какие поля и файлы уходят в облако, что возвращается, где появляются промежуточные кэши и журналы.

Закрытый контур и шлюзы

Если прямой обмен запрещен, заранее решите, где будет стоять промежуточный шлюз (например, выделенный сервер в DMZ или интеграционный контур). Проверьте, кто им управляет, как он обновляется и как в нем разделяются проекты разных подрядчиков.

Для пилота достаточно короткого плана тестов:

• один проект, два подрядчика, разные роли и права;
• одно интеграционное действие (создание заявки/замечания) и обратное подтверждение статуса;
• контроль появления копий: локально, на шлюзе, в корпоративном архиве;
• проверка отказоустойчивости: обрыв связи, повторная отправка, дубликаты;
• журналирование интеграции: кто, когда, что передал и что изменилось.

Сеть и периметр: прокси, белые списки, устойчивость соединения

Для пилота Autodesk Construction Cloud в закрытом контуре сеть часто становится главным стоп-фактором. Даже если доступ в интернет формально разрешен, детали вроде прокси, проверки сертификатов и настроек DNS ломают вход, загрузку файлов и синхронизацию.

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

Чтобы не искать причины по логам в первый же день, согласуйте базовые вещи до старта:

• список разрешенных доменов и портов, требования к TLS и цепочке сертификатов;
• правила прокси (аутентификация, ограничения по размерам файлов, таймауты);
• политики SSL inspection и исключения для критичных сервисов;
• базовые сервисы: DNS, NTP (точное время), доступ к CRL/OCSP;
• ограничения межсетевых экранов между сегментами (клиенты, админы, подрядчики).

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

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

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

Журналирование и аудит: события, выгрузки, SIEM

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

Минимальный набор событий, который обычно нужен ИБ и внутреннему контролю:

• аутентификация (успешные и неуспешные входы, выходы, смена пароля, MFA);
• права (выдача и отзыв ролей, изменения групп, изменения настроек доступа);
• данные (загрузка, скачивание, удаление, переименование, перемещение файлов и моделей);
• администрирование (изменения настроек проекта, подключение/отключение интеграций);
• экспорты (кто и когда сформировал выгрузку, какой объем и куда сохранено).

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

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

Для SIEM обычно полезнее отправлять не все подряд, а события, которые дают сигнал и контекст: входы, изменения прав, массовые удаления, необычные скачивания, операции экспорта. В пилоте заранее договоритесь о правилах корреляции и о том, какие поля нужны (пользователь, проект, IP/узел, время, действие, объект).

Простой сценарий проверки: подрядчик заявляет, что «файлы пропали». По журналам должно восстанавливаться:

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

Экспорты и архивирование: как не потерять контроль над данными

Если Autodesk Construction Cloud в закрытом контуре рассматривается как рабочая среда, заранее решите, какие данные вы обязаны уметь забрать в любой момент и в каком виде. Это снижает риск, что пилот закончится, а доказательная база по проекту останется «внутри».

Составьте перечень того, что должно попадать в выгрузку. Обычно важны не только файлы, но и контекст: кто, когда и какую версию согласовал.

• исходные файлы и все версии (включая пометки и комментарии);
• метаданные (атрибуты, статусы, связи, участники);
• отчеты и реестры (замечания, проверки, RFI, согласования);
• журналы действий по ключевым операциям;
• материалы для передачи заказчику (комплекты, ведомости, сводные выгрузки).

Формат архива должен подходить для хранения годами и для передачи между организациями. Проверьте, открываются ли выгруженные файлы без привязки к внутренней структуре проекта, сохраняются ли имена, даты, версии и идентификаторы. Отдельно уточните, можно ли выгрузить отчеты в «плоском» виде (например, таблицей) и приложить понятный манифест состава архива.

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

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

План выхода лучше прописать до старта пилота: за сколько часов делается финальная выгрузка, кто подтверждает полноту, где хранится «золотая» копия и как вы передаете ее заказчику.

Пошаговый план проверки перед пилотом

Чтобы пилот Autodesk Construction Cloud в закрытом контуре дал честный результат, заранее зафиксируйте, что именно вы проверяете и чем будете подтверждать выводы. Иначе он быстро превращается в набор разрозненных тестов без доказательств для ИБ и закупок.

Шаги до старта

1. Выберите 1-2 типовых процесса, которые болят сильнее всего: согласование ПД/РД, выдача РД подрядчикам, работа с коллизиями. Опишите участников, статусы и артефакты на выходе.

2. Подготовьте тестовые данные и пользователей. Нужны минимум два набора: маленький (быстрый прогон) и большой (проверка производительности и экспорта). Заранее заведите роли: заказчик, генпроектировщик, подрядчик, аудит.

3. Настройте доступы: SSO/MFA, роли и права, модель приглашения подрядчиков. Сразу проверьте, как отключается доступ по окончании договора и как работает разделение проектов по организациям.

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

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

После этого сведите результаты в один чеклист: что прошло, что прошло с ограничениями, что не прошло. По каждому риску назначьте владельца и срок исправления. Если пилот делаете совместно с подрядчиком или интегратором, заранее договоритесь, кто собирает доказательства для ИБ и кто отвечает за повторные тесты.

Частые ошибки в закрытом контуре

Самые неприятные истории с пилотом Autodesk Construction Cloud в закрытом контуре происходят не из-за функционала, а из-за того, что базовые договоренности и настройки оставили «на потом».

Организационные промахи

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

Еще одна типовая ошибка - смешивать тест и работу. Когда в одном пространстве живут учебные модели и реальные проекты, права доступа начинают «течь», а пользователи привыкают к обходным схемам.

Технические сюрпризы, которые ловятся заранее

Прокси и SSL inspection проверяют в последнюю очередь. Потом загрузки «падают», предпросмотр не открывается, а виноватыми оказываются пользователи. Лучше заранее согласовать, какие домены и типы трафика разрешены, и кто отвечает за исключения.

Также часто не договариваются про экспорт и архив. Если нет плана выхода (какие данные выгружаем, в каком формате, где храним, кто подписывает акт), пилот превращается в зависимость от текущих настроек.

Наконец, логи собирают «для галочки». Чтобы журналирование реально помогало, заранее ответьте на три вопроса: какие события критичны, кто смотрит оповещения и как быстро можно собрать первичную картину.

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

Пример сценария пилота: крупный заказчик и подрядчики

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

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

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

Что проверить в пилоте, чтобы не получить сюрпризы через неделю:

• приглашения внешних (кто создает аккаунты, как подтверждается личность, как быстро отключается доступ);
• разделение данных (папки и права для субподрядчиков, запрет на лишние выгрузки);
• журналы (какие события пишутся, как часто можно выгружать, куда складывать);
• экспорт и архив (регулярный экспорт моделей, чертежей, замечаний и метаданных по расписанию, проверка восстановления из архива);
• процедуры реагирования (что считается инцидентом и кто принимает решение об остановке пилота).

Критерии успеха фиксируют заранее: согласование замечаний стало быстрее (например, с 3 дней до 1), не было нарушений политики ИБ, а журналы и выгрузки покрывают ключевые действия и проходят внутреннюю проверку.

Быстрый чеклист и следующие шаги

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

Короткий чеклист:

• Доступы: кто администратор, как выдаются роли, есть ли тестовые учетные записи, как работает отключение.
• Сеть: прокси/фаервол, белые списки, стабильность соединения, кто подтверждает сетевые настройки.
• Хранение данных: где хранятся файлы, требования по резидентности, резервное копирование и срок хранения.
• Логи и аудит: какие события нужны, куда выгружаются, кто читает и как быстро реагирует.
• Экспорты: какие форматы допустимы, где лежит архив, как проверяется полнота выгрузок.

Чтобы пилот был проверяемым, заведите «папку пилота» в согласованном корпоративном хранилище и складывайте туда артефакты: согласованные требования и матрицу ролей, схему данных, сетевые настройки, результаты тестов (экспорт, восстановление, проверка журналов), протоколы и подтверждения.

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

Если нужно «свести в одно» сеть, рабочие места, инфраструктуру и процессы поддержки под требования закрытого контура, это часто удобнее делать с системным интегратором. Например, GSE.kz как производитель и интегратор ИТ-инфраструктуры в Казахстане может закрыть смежные задачи пилота (рабочие станции, серверы, контур, поддержка 24/7), чтобы технические ограничения не мешали проверить сами процессы и контроль данных.