Удаленка навсегда:
как выстроить IT-инфраструктуру для территориально распределенной команды

По мнению экспертов, в 2026 году удаленная работа становится всё более востребованной и доступной для различных профессий. Особенно в ИТ-сфере. Дистанционный формат здесь наиболее распространён, что связано со спецификой задач и возможностью их выполнения вне офиса. По данным Superjob, доля вакансий с удалённым и гибридным форматом составляет 10–11% по рынку труда в целом и 33–35% в сфере информационных технологий.

1. Вы перевели команду на постоянную удаленку. Какие сервисы и инструменты оказались критичными для работы, а без каких можно было обойтись? Что вы внедрили в первую неделю, а что — через полгода, когда поняли реальные потребности?
2. Расскажите о случае, когда удаленный сотрудник не мог работать из-за проблем с инфраструктурой (VPN упал, доступ закрыли, канал лег). Как быстро вы отреагировали? Что изменили в архитектуре после этого инцидента?
3. Как вы обеспечиваете безопасность при удаленной работе? VPN, двухфакторная аутентификация, VDI, Zero Trust — что используете? Были ли случаи утечек или компрометаций через удаленный доступ? Как защитились?
4. Сколько реально стоит поддержка одного удаленного сотрудника в месяц? Включите в стоимость не только лицензии и облака, но и оборудование, интернет, поддержку, безопасность. Оказалось дороже или дешевле офиса?
5. Вы используете свои серверы, облака или гибрид для удаленной инфраструктуры? Почему выбрали именно такую модель? Что бы изменили сейчас, оглядываясь назад?
6. Как вы решаете проблему производительности, когда сотрудники работают из разных регионов или стран с разным качеством интернета? Используете ли CDN, локальные кэши, оптимизацию трафика? Что реально помогает?
7. Расскажите о случае, когда вы предоставляли оборудование удаленному сотруднику (ноутбук, монитор, периферию), и это создало проблемы (потерял, сломал, не вернул). Как вы теперь управляете парком устройств?
8. Как вы обеспечиваете резервное копирование и аварийное восстановление для распределенной команды? Где хранятся бэкапы — централизованно или у сотрудников? Были ли случаи потери данных?
9. Вы мониторите инфраструктуру для удаленной команды. Какие метрики оказались критичными (доступность VPN, задержки, нагрузка на серверы)? Как вы понимаете, что «всё работает», когда не видите сотрудников?
10. Если бы вы сейчас начинали выстраивать инфраструктуру для удаленной команды с нуля, то что бы сделали иначе? Какие ошибки не повторили бы? С чего начали бы?

На вопросы «СА» отвечают эксперты ИТ-отрасли

Юлия Петрова,
заместитель генерального директора, директор по корпоративному управлению «Кит-системс

«Недавно мы защитили информационную систему от внешних киберугроз и внедрили систему анализа сетевого трафика на базе отечественных ИБ-решений»

Удаленный режим работы в чистом виде был вынужденной мерой в эпоху COVID’ных ограничений, после снятия которых постепенно трансформировался в гибридный формат, по сей день сохранившийся у весьма немногочисленных компаний.

Тем не менее, пандемийный опыт показал, что ИТ-системы бизнеса должны быть готовы к быстрому переводу значительной части сотрудников на дистанционную работу. Поэтому в прошлом году мы перевели собственную инфраструктуру и информационные системы дочерней компании «Кит-софт» на российскую облачную платформу Яндекс 360, позволившую одномоментно обеспечить доступ сотрудников практически ко всем корпоративным ИТ-сервисам.

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

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

Как мы обеспечиваем безопасность при удаленной работе? Мы опираемся на связку интегрированных в облачную платформу инструментов кибербезопасности (шифрование данных, контроль доступа, антивирусная/антиспам защита, и т.д.) с комплексом on-premise-решений, локализованными в информационном контуре компании. Портфель последних постоянно расширяем и актуализируем вслед за изменением профиля потенциальных угроз.

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

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

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

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

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

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

Максим Захаренко,
СЕО «Облакотека»

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

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

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

Это обычно внедряется в первую неделю, потому что без этого команда просто не сможет работать. А вот через несколько месяцев становятся видны более глубокие потребности — например, централизованное управление рабочими местами, мониторинг доступности сервисов, контроль устройств, VDI для отдельных категорий сотрудников, DLP, расширенная аналитика по инцидентам.

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

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

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

Zero Trust как подход тоже полезен, но его важно не превращать в модное слово. Смысл простой: не доверять устройству и пользователю автоматически, а проверять контекст каждого подключения.

По стоимости удаленный сотрудник не всегда дешевле офисного. Экономия на рабочем месте в офисе может компенсироваться затратами на ноутбук, лицензии, VPN, MDM, антивирус, резервное копирование, поддержку, иногда компенсацию интернета — то есть все те же самые затраты. В среднем считать нужно не только прямые лицензии, но и время ИТ-команды. Именно поддержка часто оказывается скрытой статьей расходов: чем менее стандартизированы устройства и доступы, тем дороже сопровождение.

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

Производительность зависит не только от мощности серверов, но и от маршрута до пользователя. Если сотрудники работают из разных городов или стран, важно смотреть на задержки, качество каналов, доступность сервисов, нагрузку на VPN, время отклика бизнес-приложений. Где-то помогают локальные кэши, где-то — оптимизация трафика, где-то — перенос части сервисов ближе к пользователям. Но чаще всего самый заметный эффект дает не CDN, а нормальная архитектура доступа и отказ от передачи тяжелых файлов туда-сюда.

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

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

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

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

Ильяс Салихов,
сооснователь и CTO RetailCRM

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

При переводе команды на дистанционную работу у нас не было необходимости во внедрении новых инструментов. Компания работает в нескольких филиалах и основные, стандартные инструменты уже были настроены для работы — корпоративный VPN и вайтлистинг. Так как есть международный проект, для зарубежных коллег мы дополнительно настраивали доступы к российским сайтам.

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

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

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

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

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

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

Илья Глейкин,
независимый бизнес-консультант в области ИТ-менеджмент

«Удаленка навсегда — это не „выдали ноутбук и забыли“, а постоянная дисциплина: доступы, устройства, бэкапы, метрики, поддержка и регулярная уборка всего лишнего»

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

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

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

По безопасности удаленка быстро лечит от веры в один только VPN. Мы добавили второй фактор, выпуск сертификатов на устройства, сегментацию сети, правила на АВПО, SIEM и мониторинги, пересмотрели процессы предоставления доступов.

Позже начали двигаться к Zero Trust: проверять не только пользователя, но и устройство, контекст, необходимость доступа. Были и попытки аккуратного перебора логинов к веб-почте — немного учетных записей, по 2–3 попытки, чтобы не шуметь.

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

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

Если бы начинал сейчас с нуля, то начал бы не с VPN и героизма ИТ-службы, а с каталога сервисов, профилей сотрудников, матрицы доступов, MFA, мониторинга и понятной модели стоимости владения.

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

Татьяна Попова,
исполнительный директор ЕМДЕ

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

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

С самого начала у нас был гибридный формат. Сотрудники могли работать 50/50 из офиса или удаленно. Постепенно потребность в офисах снизилась до нуля. Поэтому при переходе на полную удаленку нам не пришлось ничего изобретать с точки зрения инфраструктуры. Все обязательные сервисы — VPN, почта, гит, CI/CD, трекер и т.п. были развернуты в облаке.

Мы также используем свой собственный продукт — корпоративный портал Инкоманд для взаимодействия внутри команды. Несколько лет назад мы перешли на КЭДО — это еще один важный элемент для удаленки, так как с ним ушла отправка бумаг курьерами. При закрытии офисов перенесли только несколько песочниц с локального сервера разработки. Чтобы открыть новый офис нам сейчас достаточно снять помещение, завезти мебель и подключить интернет.

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

Как мы обеспечиваем безопасность при удаленной работе? Тут всех секретов не раскроем! Это конфиденциальная информация в каждой компании. В целом можно выделить VPN + SSO с двухфакторной аутентификацией и размещение всех сервисов, не предназначенных для доступа потенциальных клиентов, в отдельном изолированном и защищённом сегменте сети. Мы считаем, что это минимальный джентельменский набор любой ИТ-компании. В ИБ побеждает не тот, кто изобрел велосипед — инструменты всем известны, а тот, кто не поленился и ответственно к этому отнесся.

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

Все сотрудники у нас в России и понимают, что в рабочее время надо быть на проводном интернете, а не в поле с gsm-модемом. Поэтому вопрос о качестве интернета и штатном режиме работы у нас не стоит.

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

У нас достаточно ответственные сотрудники, ничего не теряли. Бухгалтерия ведет учет, что кому выдано. Мы даже сделали себе удобное представление с реестром в корппортале. Но один необычный случай был.

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

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

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

Мы осуществляем мониторинг доступности сервисов, а также централизованный сбор журналов и ошибок на базе стека ELK (Elasticsearch, Logstash и Kibana). При критических ошибках настроены уведомления. У нас в компании достаточно эффективные коммуникации, поэтому если какой-то сервис ведет себя странно и этот кейс «не покрыт» мониторингом, ответственный за него специалист сразу получает шаги воспроизведения и описание отклонения от ожидаемого поведения вместо «что-то у меня плохо работает».

Мы изначально выстраивали работу под удаленку и рады, что у нас получилось. Незначительные ошибки были, но связанные не с удаленной работой, а с выбором конкретных сервисов. 6 лет назад мы использовали Google workspace — там лучший почтовый клиент и совместное онлайн-редактирование офисных файлов. Поэтому исторически с файлами мы работали и там, и в нашем корпортале. При переходе с Гугл на Яндекс мы сохранили этот принцип. Но в ходе эксплуатации от Яндекс.диска отказались — удобнее со всеми файлами работать в Инкоманд.

Сергей Халяпин,
директор по развитию новых рынков и технологических партнеров Termidesk (компания ООО «Увеон-облачные технологии», входит в «Группу Астра»)

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

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

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

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

Именно здесь появляется VDI. С помощью нашего продукта Termidesk VDI 7.0 можно обеспечить разные сценарии удалённого доступа: виртуальные рабочие места, терминальный доступ, доставку приложений и удаленный доступ к физическим ПК. Это важно, потому что у компаний редко бывает один сценарий, подходящий для всех сотрудников. Одним нужен полноценный десктоп виртуальной машины, другим — опубликованное приложение, третьим — доступ к уже существующей физической станции, так как на ней установлено спецПО или подключено уникальное оборудование.

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

Случай, когда удаленный сотрудник не мог работать из-за проблем с инфраструктурой? Здесь надо разделять потенциальные проблемы с инфраструктурой, так как в ряде случаев при проектировании инфраструктуры удалённого доступа без учёта катастрофоустойчивости и непрерывности ведения бизнеса (DR и BC), например, при полном отказе сетевых подключений, удалённая работа будет невозможна.

Но есть много типовых случаев, особенно актуальных в настоящее время: удаленный сотрудник не может начать рабочий день, потому что недоступен VPN-шлюз или VPN-траффик заблокирован оператором. Возможны временные решения — переключить пользователя на резервный канал, настроить альтернативный шлюз или протокол, предоставить доступ к резервной площадке с необходимым набором ИТ-ресурсов.

Но правильный вывод из такого инцидента — не «починить VPN», а пересмотреть архитектуру удалённого доступа. Если ИТ-составляющая бизнеса является жизненно важной, то нельзя строить инфраструктуру вокруг одной точки отказа.

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

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

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

Ошибка, которую часто допускают при расчете стоимости удаленного рабочего места — считают только лицензии на решение VDI. На практике нужно учитывать большое количество составляющих: устройство пользователя, необходимая для работы периферию, стоимость организации или расширения офисного Интернет-канала, а также компенсация затрат пользователя на связь, лицензии на VDI и возможно на дополнительные программные продукты, стоимость серверного оборудования и СХД, инструменты для обеспечения безопасности удалённого доступа, дополнительный мониторинг, организацию удалённой поддержки и администрирования пользователей.

Удаленка может быть дешевле офиса, особенно, если компания сокращает расходы на представительскую часть офисного и парковочного пространства, рабочие места, помещения и локальную поддержку. Вместо огромного офиса класса «А+» в центре Москвы, компания оставит небольшое пространство для проведения личных встреч с важными клиентами.

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

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

Причина простая: у пользователей удаленной инфраструктуры разные требования. Кому-то (ряду отделов и департаментов) важнее безопасность и контроль, кому-то — скорость внесения изменений, кому-то — географическая близость к пользователю (из-за ограничений сетевой инфраструктуры). Постоянная удаленка быстро показывает, что инфраструктура должна быть не только безопасной, но и переносимой между различными платформами.

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

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

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

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

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

Второй уровень-минимизация зависимости от устройства. Чем меньше данных и бизнес-логики находится на ноутбуке сотрудника, тем ниже риск. Более того, возможность предложить сотруднику использовать его личное устройств (так называемые BYOD или CYOD программы) является хорошим вариантом избегания проблем с пользовательскими устройствами.

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

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

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

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

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

Критичные метрики для администраторов инфраструктуры: доступность портала и компонентов Termidesk, состояние узлов, доступность поставщиков ресурсов, количество активных и зависших сессий, нагрузка на серверы, состояние фондов рабочих мест и скорость создания новых ВРМ. А вот тем, кто отвечает за поддержку пользователей более важными метриками будут: время подключения сотрудника к необходимому ему ресурсу, ошибки аутентификации, задержки в сети, состояние каналов передачи данных, доступность шлюзов.

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

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

Мы бы начали с классификации пользователей и их потребностей: кому нужен полноценный VDI; кому-то опубликованное приложение; кто-то потребует доступ к физическому ПК. Затем описали бы политики безопасности, модель аутентификации, обеспечение резервирования инфраструктуры, особенно в разрезе DR и BC и определились с требованиями к мониторингу. Только после этого выбирали бы конкретные технологии.

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

Динислам Вахитов,
заместитель директора департамента эксплуатации и технической поддержки CommuniGate Pr

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

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

В кратчайшие сроки был сделан необходимый минимум, чтобы люди могли полноценно работать:

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

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

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

Некоторые модные штуки, вроде тотального VDI «для всех», остались в виде аккуратных пилотов — практика показала, что для большинства задач это лишь усложняет инфраструктуру, не давая преимуществ.

Был показательный эпизод: у одного из сотрудников внезапно пропал доступ ко всем корпоративным сервисам: почте, CRM, хранилищу данных. С стороны это выглядело как «всё сломалось», хотя на самом деле проблема оказалась связана с единственным шлюзом удаленного доступа и качеством связи в его регионе.

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

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

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

Самое сложное при удаленной работе — отказаться от привычного подхода «есть внутренняя сеть, и там всё наше». Как только сотрудники начали работать из дома, коворкингов и чужих сетей Wi‑Fi, эта модель перестала работать.

Поэтом пришлось перестроиться:

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

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

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

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

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

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

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

Причин такого выбора несколько:

1. Команда привыкла работать с виртуальной инфраструктурой как с классическим on‑prem: свои виртуальные машины, свои подсети, маршрутизаторы, правила, кластеры. Полностью переходить на SaaS-модель не было необходимости.
2. Обслуживанием оборудования, площадок, электропитанием и отказоустойчивостью на уровне гипервизора занимается провайдер, мы можем сосредоточиться на том, что относится к области нашей компетенции: удаленный доступ, почта, приложения, мониторинг, бэкап.
3. Такая архитектура позволяет логично разделить инфраструктуру на отдельные сегменты: отдельно ядро (каталог, почта, доступ), отдельно пользовательские сервисы, отдельно окружения для разработки и тестов, отдельно — сервисы, доступные извне. Это существенно упрощает обеспечение безопасности и повседневную эксплуатацию.

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

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

Поэтому мы предприняли несколько шагов:

• организовали несколько точек входа, чтобы сотрудник подключался к ближайшей из них, а дальше трафик уже шел нашему маршруту до сервисов;
• аккуратно подбирали протоколы и параметры MTU/MSS, чтобы избежать проблем с соединением у разных интернет-провайдерах;
• перенесли тяжёлые данные на серверную сторону, чтобы по сети передавался только пользовательский трафик, а не большие объемы данных.

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

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

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

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

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

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

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

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

Были случаи, когда важные данные оставались только на локальном устройстве и были утрачены вместе с ним. Это стало хорошим уроком — после этого мы ужесточили требования к хранению рабочих данных, а нарушения перестали «списываться на случайность».

Как мы понимаем, что «всё работает», когда не видим сотрудников? В офисе все достаточно легко: если что-то серьёзно сломалось, об этом становится известно почти сразу.

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

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

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

С опытом понимаешь, что самая большая ошибка — начинать с «быстрого» и «упрощённого» варианта, а всё серьёзное откладывать «на потом». В распределённой модели это «потом» обычно наступает в самый неудобный момент.

Если бы сегодня пришлось выстраивать инфраструктуру с нуля, я бы сделал бы так:

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

Самое важное, пожалуй, — относиться к удалёнке не как к «временной мере», а как к нормальному, постоянному режиму работы. Тогда решения получаются куда более взвешенными.

Ключевые слова: удаленная работа, распределенная команда, ИТ-инфраструктура

Подпишитесь на журнал

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