Облачный интернет
и новое поколение сетевых решений

Будущее ИТ-архитектуры заключается в гибкости и мгновенном масштабировании ресурсов.

1. Раньше трафик шел в офис, а потом в облако. Теперь он идет прямо в облако. Какая бизнес-задача решается этим самым прямым маршрутом?
2. Если сеть становится «облачной услугой», то ИТ-отдел платит за трафик или за «гарантированный доступ»? Как меняется финансовая модель?
3. Где теперь находится «центр управления» безопасностью, если нет единого корпоративного сетевого периметра? В облаке провайдера или в вашем аккаунте?

На вопросы «Системного администратора» отвечают эксперты ИТ-компаний

Константин Исаев,
технический эксперт компании mrnet

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

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

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

Меняется и экономика ИТ. Важным остается доступность — сколько времени сервис реально доступен, какие задержки и потери допустимы, как ведет себя сеть при падении одного из каналов. Это проще привязать к деньгам: простой касс, стоп логистики или недоступность CRM — прямые потери, а не абстрактные скорости в договоре. SLA SaaS ориентированы на непрерывность работы услуг.

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

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

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

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

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

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

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

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

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

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

Отдельно — питание и физика. Никакая модель не спасет, если узел или объект не переживает краткие отключения электричества или стоит в проблемной зоне. Это решается локальной автономностью (например, установка мультироутера с встроенным АКБ) и корректным размещением, и об этом часто забывают, теряя драгоценные минуты или часы в простое терминалов оплаты.

Как снизить риски при переходе? Лучший сценарий — пилот. Начинайте не со всей сети, а с 1–2 типовых точек: филиал, склад, торговая точка, удаленный офис. Это дает реальную картину поведения сервисов, выявляет узкие места и позволяет корректировать политики без риска для бизнеса. Вы сможете правильно оценить предлагаемый потенциал, не меняя привычной модели.

Далее — параллельная работа старой и новой модели на этапе внедрения. Это снимает напряжение и дает сравнение по фактическим метрикам, а не по ощущениям: задержка, стабильность, число инцидентов, влияние на процессы. Вы также можете использовать новую модель в качестве резерва, плавно переводя её в основу.

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

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

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

Андрей Малов,
директор по продукту «ТТК.Облако»

«Прямой маршрут в облако требует новой модели защиты, и это — эшелонированная (многоуровневая) защита, которая гарантирует безопасность»

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

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

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

Вместо одного «щита» появляются несколько независимых уровней защиты:

• Физический — инфраструктура размещается в Tier III дата-центрах с СКУД, ИБП и круглосуточным контролем;
• Сетевой — NGFW, IPS/IDS и ГОСТ-VPN обеспечивают шифрование и фильтрацию трафика между пользователем и облаком;
• Виртуальный — микросегментация и RBAC изолируют компоненты внутри облака, не позволяя угрозе «расползтись»;
• Прикладной — WAF, DDoS-защита и API-безопасность охраняют непосредственно бизнес-логику;
• Данные — шифрование, многофакторная аутентификация и резервное копирование гарантируют целостность и доступность.

2. В ТТК.Облако все сервисы безопасности можно арендовать по модели подписки «Безопасность как сервис» (SECaaS). Таким образом клиент платит не за объём трафика, а за гарантированный уровень защиты и доступности в рамках сервиса. Финансовая модель смещается от капитальных затрат (CapEx): клиент получает готовые, масштабируемые решения без необходимости закупать оборудование или разворачивать собственную инфраструктуру безопасности.

3. В условиях размытого периметра центр управления безопасностью сосредоточен в Едином центре мониторинга информационной безопасности (ЕЦМИБ), который находится под управлением SOC ТТК.

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

Николай Барков,
генеральный директор ИТ-компании Lansecurity

«При переходе к облачной модели сети финансовая модель радикально меняется. ИТ-отдел теперь платит не за объем трафика, а за фактическое использование услуг. Эта модель делает оплату более справедливой»

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

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

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

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

• CSPM (Cloud Security Posture Management) для управления состоянием безопасности облака и выявления рисков и неправильных конфигураций.
• CWPP (Cloud Workload Protection Platform) для защиты рабочих нагрузок в мультиоблачных и гибридных средах.
• CNAPP (Cloud-Native Application Protection Platform) — комплексные решения, объединяющие CSPM и CWPP.

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

Александр Мезенцев,
Global CIO, финтех-компания MoneyCat

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

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

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

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

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

Ключевые слова: облачный интернет, новые сетевые решения

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

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