11.03.2021

DRaaS: сценарии аварийного восстановления

План действий на случай сбоя или аварии на уровне ИТ-инфраструктуры - must have для всех компаний сегодня. Олег Федоров, менеджер по продуктам и решениям Linxdatacenter, рассказывает, как устроено аварийное восстановление на площадках Linxdatacenter с подробным разбором нюансов и сценариев развития событий

План действий на случай сбоя или аварии на уровне ИТ-инфраструктуры — must have для всех компаний сегодня. Олег Федоров, менеджер по продуктам и решениям Linxdatacenter, рассказывает, как устроено аварийное восстановление на площадках Linxdatacenter с подробным разбором нюансов и сценариев развития событий.

Что такое DRaaS и кому он нужен

Основное правило построения отказоустойчивых решений по-английски звучит в рифму и крайне точно описывает базовый подход к DRP: Two is one and one is none («Два равняется одному, один равняется нулю»).

В соответствии с этим подходом, любой критически важный элемент ИТ-системы должен быть представлен в двух экземплярах и никогда – в единственном. В самом примитивном варианте возможна модель n+1, которая предполагает оперативное «поднятие» дополнительного ресурса в случае необходимости.

Disaster Recovery as a Service (DRaaS), или аварийное восстановление ИТ-систем как услуга, заключается в создании копии физических или виртуальных серверов третьей стороной, чтобы минимизировать потери бизнеса, вызванные отказом инфраструктуры в случае техногенной катастрофы или стихийного бедствия.

DRaaS актуален для организаций, у которых нет возможностей или ресурсов для того, чтобы самостоятельно развернуть и настроить план аварийного восстановления (Disaster Recovery Plan, или DRP).

DRaaS эффективен и против кибер-угроз класса ransomware, массовый рост числа которых был отмечен ИБ-экспертами в конце 2020 года по всему миру.

Хакеры-вымогатели заработали более $350 млн в 2020 году, что на 311% больше, чем в 2019. Истинная цифра, скорее всего, будет гораздо больше, учитывая, что многие жертвы не сообщают о факте атаки и, тем более, о выплате выкупа. Некоторые аналитики оценивают подобные издержки для бизнеса на уровне $20 млрд в год.

 

Облачная отказоустойчивость как тренд

В условиях локдауна многие компании сократили свои расходы на ИТ в рамках стратегического пересмотра политики капитальных расходов (CAPEX).

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

Ожидается, что объем мирового рынка DRaaS вырастет с $5,1 млрд в 2020 году до $14,6 млрд к 2025 году при совокупном годовом темпе роста (CAGR) 23,3% в течение прогнозного периода (данные MarketsandMarkets).

Рынок будет продолжать расти под влиянием пандемии COVID-19, так как миграция ИТ-инфраструктуры в облако позволяет «прокачать» непрерывность бизнеса (business continuity) компаний, работа которых зависит от надежности цифровых сред и инструментов.  И при этом не делать значительных вложений в инфраструктуру.

Трудности перехода

Хотя многие уже готовы принять аварийное восстановление в качестве части своего плана обеспечения непрерывности бизнеса, DRaaS все еще является одним из наиболее игнорируемых направлений со стороны ИТ-подразделений по всему миру.

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

Согласно опросу, проведенному одним из ведущих игроков на рынке DRaaS, компанией Infrascale, 80% респондентов заинтересованы в использовании традиционных методов и старых технологий для аварийного восстановления.

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

Можно принять меры по снижению риска, но иногда определенные события делают простой оборудования неизбежным. DRaaS нередко критикуют как избыточную меру – «Это рассчитано на прямое попадание метеорита в ЦОД, этого никогда не произойдет».

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

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

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

 

DRP поэтапно 

DRP – комплекс действий, направленных на восстановление ИТ-инфраструктуры и данных после какой-либо аварии, сбоя или катастрофы. Неважно, с чем они связаны: проблемы на уровне ИТ-инфраструктуры, авария инженерных систем ЦОДа, человеческие ошибки, пожары, землетрясения, наводнения.

Можно выделить пять основных этапов DRP:

  • аудит ИТ-процессов с анализом и оценкой рисков;
  • разработка DRaaS-решения;
  • внедрение решения;
  • тестирование решения;
  • запуск в эксплуатацию.

На этапе разработки решения рассчитываются показатели RTO (recovery time objective) – максимально допустимое время простоя сервиса в случае сбоя, и RPO (recovery point objective) – точка возврата, или максимально допустимый объем возможных потерь данных.

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

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

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

К примеру, к затратам можно отнести маркетинговая активность, которая потребуется для работы с имиджем компании после сбоев в работе ИТ-систем.

 

Как мы защищаем ИТ-системы от сбоя 

Современная ИТ-инфраструктура включает в себя четыре базовые составляющие.

Первая – это уровень «железа» (hardware), на котором развернут второй уровень – системы виртуализации. Внутри них находится третий уровень – операционных систем, а на базе операционных систем развернут четвертый уровень – ИТ-сервисы и приложения.

Решение DRaaS, которое мы в Linxdatacenter разработали для своих клиентов, в полном объеме покрывает уровень hardware. У нас есть собственные площадки дата-центров в Москве, Санкт-Петербурге, а также облако в Варшаве.

На уровне виртуализации мы используем систему VMware, которая позволяет гарантировать высокие показатели восстановления вплоть до третьего уровня (т.е. ОС).

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

 

DR-сценарии

Самый простой вариант DR – Backup-as-a-Service (BaaS). Это disaster recovery в миниатюре. Фактически это стартовый уровень резервирования.

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

Эта схема защищает зарезервированные данные от потери в случае сбоя.

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

Почему BaaS – не совсем DRaaS и «стартовый уровень»? Потому что показатели RTO и RPO здесь очень большие. Пока мы распакуем образ сохраненной системы или данных, пока подмонтируем, пока запустим – пройдет время.

Преимуществом модели является возможность бэкапа, даже если клиент не размещает ИТ-инфраструктуру в нашем облаке. Используя Veeam Cloud Connect, клиент может выложить резервную копию на одну из наших площадок.

Если клиент не пользуется инструментами Veeam, то и на этот случай есть решение: достаточно установить специальное ПО непосредственно на виртуальную машину, которое позволит создать резервную копию и сохранить ее в облаке Linxdatacenter.

Рассмотрим более продвинутый сценарий.

У нас есть точка А, на которой работают виртуальные машины, и точка Б, куда виртуальные машины предварительно копируются.

 

 

Данные с основной площадки постоянно передаются на вторую с заданным интервалом. Таким образом RPO становится значительно меньше, потому что такое решение поддерживает обновления с периодичностью вплоть до 15-20 минут.

Если система в точке А окажется недоступной, ответственный сотрудник отреагирует и запустит инструменты Veeam для выполнения аварийного восстановления.

Запустится машина в точке Б, где нагрузку на себя примет точная копия систем клиента по состоянию на ближайший эпизод обновления (т.е. в пределах до 15 минут назад). Параллельно мы осуществляем «переезд» внешних IP-адресов. Такой запуск сценария DRP может вообще пройти незаметно для бизнеса клиента.

В случае, если клиент использует собственную архитектуру, мы задействуем Veeam Cloud Connect – через него мы можем подцепить не только бэкапы к себе в облако, но и организовать всю необходимую заказчику инфраструктуру. Единственная оговорка: IP-адреса не будут работать по причине использования сети третьей стороны.

В данной модели DRP показатель RTO составит примерно 20 минут. Через 20 минут поднимутся виртуальные машины и инфраструктура заказчика на второй площадке (точке Б). RPO же составит примерно 30 минут с момента запуска аварийного сценария.

 

В ручном режиме

Надо понимать, что операции по аварийному восстановлению всегда выполняются в ручном режиме. Любая автоматизация процесса восстановления может вызвать ложные срабатывания и ситуации по типу split head.

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

В 99% таких случаев вся инфраструктура падает, потому что каждая точка пытается «перетянуть одеяло» на себя. Сервисы просто перестают быть доступными, и нужно распутывать этот клубок руками.

Поэтому инициация DRP, переезд IP-адресов и прочее – все происходит в ручном или полуавтоматическом режиме.

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

Чтобы максимально упростить процесс для конечного пользователя, можно предложить ему специальную консоль для управления DRP. Если точка становится недоступна, сотрудник нажимает кнопку «Запустить DRP», и после получения команды Veeam при помощи технологии Veeam Replica запускает виртуальные машины в точке Б.

Также клиент должен написать отправить запрос на перевод IP-адресов, если он использует каналы связи Linxdatacenter. Если же сетевые ресурсы предоставляет третья сторона, на двух площадках ставится инструмент load balancer от Citrix, а между площадками назначается виртуальный IP-адрес. В результате мы получаем два разных физических и один виртуальный внешний IP-адрес.

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

 

Расчет стоимости 

Написать стандартные скрипты сервисов DRaaS для всех клиентов практически невозможно. У каждого клиента уникальная ИТ-инфраструктура и задачи.

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

Любой план DRP, даже с учетом фиксированных и гарантированных провайдером решения параметров, потребует «подгонки» под реалии конкретной компании.

Определять, какая базовая модель нужна компании – BaaS или DRaaS, – также нужно, исходя из анализа потребностей компании.

BaaS – это просто копия данных клиента, которая лежит зачастую на той же площадке, что и исходник, для восстановления стандартными средствами также на основной площадке. Это «подстраховка» на всякий случай.

DRaaS всегда предполагает защиту от какой-то серьезной катастрофы, будь то национальный или региональный блэкаут, стихийное бедствие (наводнение, землетрясение), война или прямое попадание метеорита в ЦОД с системами клиента.

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

В BaaS для расчета стоимости применяется модель «pay as you go», когда клиент платит за место на диске, а за ресурсы CPU и RAM плата рассчитывается только в определенном объеме, в зависимости от масштабов восстановленной системы и только в случае активации сценария.

Стоимость DRaaS включает в себя много параметров и рассчитывается индивидуально

 

Когда спасает только DRaaS

Бэкап перекрывает многие потребности, но далеко не все.

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

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

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

 

Это решение построено на инструменте CloudEndure Disaster Recovery и позволяет устанавливать агента на виртуальную машину клиента. Далее через консоль управления ВМ реплицируется в облако AWS. Процесс носит непрерывный характер и охватывает ОС, конфигурации состояния системы, приложения и файлы.

CloudEndure Disaster Recovery можно использовать для защиты самых важных баз данных, в том числе Oracle, MySQL и SQL Server, а также корпоративных приложений, таких как SAP.

В случае аварии решение позволяет за несколько минут автоматически запустить тысячи ВМ в состоянии полной готовности.

Стоит отметить, что AWS-сценарий как DRP – самое эффективное, но и самое дорогостоящее решение: стоимость включает затраты на виртуальные машины, дисковое пространство, а также лицензию на CloudEndure и дополнительные сервиcы AWS.

 

3,2,1…и последний вывод

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

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

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

Надежный план резервного копирования подкрепляет общую ИБ-политику компании. Хорошим началом здесь будет так называемая «Стратегия 3,2,1»: три копии данных – две из них хранятся локально, но в разных частях, еще одна – вне площадки.

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

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

News and publications

You may also be interested in

Write to us

How we optimized customer data center management

Data center is a complex IT and engineering object, which requires professionalism at all levels of management: from managers to technical specialists and executors of maintenance works. Here's how we helped our client put operational management in corporate data centers in order.
 

Taras Chirkov, Head of Data Center in St. Petersburg  in St. Petersburg 

Konstantin Nagorny, chief engineer of data center in St. Petersburg.  in St. Petersburg 

Data center is a complex IT and engineering object, which requires professionalism at all levels of management: from managers to technical specialists and executors of maintenance works. Here's how we helped our client put operational management in corporate data centers in order.  

Management is in the lead 

The most advanced and expensive IT equipment will not bring the expected economic benefits if proper processes of engineering systems operation in the data center, where it is located, are not established.  

The role of reliable and productive data centers in today's economy is constantly growing along with the requirements for their uninterrupted operation. However, there is a big systemic problem on this front.  

A high level of "uptime" - failure-free operation of a data center without downtime - depends very much on the engineering team that manages the site. And there is no single formalized school of data center management.  

And there is no single formalized school of data center management.    

Nationwide  

In practice, the situation with the operation of data centers in Russia is as follows.  

Data centers in the commercial segment usually have certificates confirming their management competence. Not all of them do, but the very specifics of the business model, when a provider is responsible to the client for the quality of service, money and reputation in the market, obligates them to own the subject. 

The segment of corporate data centers that serve companies' own needs lags far behind commercial data centers in terms of operational quality. The internal customer is not treated as carefully as the external customer, not every company understands the potential of well-configured management processes. 

Finally, government departmental data centers - in this regard, they are often unknown territory due to their closed nature. An international audit of such facilities is understandably impossible. Russian state standards are just being developed.  

This all translates into a "who knows what" situation. "Diverse" composition of operation teams composed of specialists with different backgrounds, different approaches to the organization of corporate architecture, different views and requirements to IT departments.  

There are many factors that lead to this state of affairs, one of the most important is the lack of systematic documentation of operational processes. There are a couple of introductory articles by Uptime Institute which give an idea of the problem and how to overcome it. But then it's necessary to build the system by your own efforts. And not every business has enough resources and competence for that.  ⠀⠀  

Meanwhile, even a small systematization of management processes according to industry best practices always yields excellent results in terms of improving the resilience of engineering and IT systems.  

Case: through thorns to the relative order 

Let's illustrate by the example of an implemented project. A large international company with its own data center network approached us. The request was for help to optimize the management processes at three sites where IT systems and business-critical applications are deployed.  

The company had recently undergone an audit of its headquarters and received a list of inconsistencies with corporate standards with orders to eliminate them. We were brought in as a consultant for this as a bearer of industry competence: we have been developing our own data center management system and have been educating on the role of quality in operational processes for several years.  

Communication with the client's team began. The specialists wanted to get a well-established system of data center engineering systems operation, documented on the processes of monitoring, maintenance and troubleshooting. All this had to ensure optimization of the infrastructure component in terms of IT equipment continuity.  

And here began the most interesting part.  

Know thyself 

To assess the level of data centers in terms of compliance with standards, you need to know the exact requirements of the business to IT systems: what is the level of internal SLA, the allowable period of equipment downtime, etc.  

It became clear right away that the IT department did not know exactly what the business wanted. There were no internal criteria of service quality, no understanding of the logic of their own infrastructure.  

Colleagues simply had no idea what the permissible downtime for IT-related operations was, what the optimal system recovery time in case of a disaster was, or how the architecture of their own applications was structured. For example, we had to figure out whether a "crash" of one of the data centers would be critical to the application, or if there were no components affecting the application.  

Without knowing such things, it is impossible to calculate any specific operational requirements. The client recognized the problem and increased coordination between IT and the business to develop internal requirements and establish relationships to align operations.  

Once an understanding of the IT systems architecture was achieved, the team was able to summarize the requirements for operations, contractors, and equipment reliability levels.  

Improvements in the process 

Our specialists traveled to sites to assess infrastructure, read existing documentation, and checked the level of compliance of data center projects with actual implementation.  

Interviews with the responsible employees and their managers became a separate area of focus. They told what and how they do in different work situations, how the key processes of engineering systems' operation are arranged.  

After starting the work and getting acquainted with the specifics of the task the client "gave up" a little: we heard the request "just to write all the necessary documentation", quickly and without deep diving into the processes.  

However, proper optimization of data center "engineering" management implies the task to teach people to properly assess the processes and write unique documentation for them based on the specifics of the object.  

It is impossible to come up with a working document for a specific maintenance area manager - unless you work with him at the site continuously for several months. Therefore this approach was rejected: We found local leaders who were willing to learn themselves and lead their subordinates.  

Having explained the algorithm of documents creation, requirements to their contents and principles of instructions ecosystem organization, for the next six months we controlled the process of detailed writing of documentation and step-by-step transition of the personnel to work in a new way. 

This was followed by a phase of initial support for work on the updated regulations, which lasted one year in a remote format. Then we moved on to training and drills - the only way to put the new material into practice.  

What's been done 

In the process, we were able to resolve several serious issues.  

First of all, we avoided double documentation, which the client's employees feared. To this end, we combined in the new regulations the regulatory requirements applied to various engineering systems as standard (electrics, cooling, access control), with industry best practices, creating a transparent documentation structure with simple and logical navigation.   

The principle of "easy to find, easy to understand, easy to remember" was complemented by the fact that the new information was linked to the old experience and knowledge of the employees. 

Next, we reshuffled the staff of service engineers: several people turned out to be completely unprepared for the change. The resistance of some was successfully overcome in the course of the project through the demonstration of benefits, but a certain percentage of employees turned out to be untrained and unresponsive to new things.  

But we were surprised by the company's frivolous attitude to its IT infrastructure: from the lack of redundancy of critical systems to the chaos in the structure and management.  

In 1.5 years the engineering systems management processes have been pumped up to the level that allowed the company's specialists to successfully report "for quality" to the auditors from the headquarters.  

With the support of the operating component development pace the company will be able to pass any existing certification of data centers from leading international agencies.  

Summary 

In general, the prospects of consulting in the field of operational management of data centers, in our opinion, are the brightest.  

The process of digitalization of the economy and the public sector is in full swing. Yes, there will be a lot of adjustments in the launch of new projects and plans for the development of old ones, but this will not change the essence - the operation should be improved at least to improve the efficiency of already built sites.  

The main problem here: many managers do not understand what thin ice they are walking on, not paying proper attention to this point. The human factor is still the main source of the most unpleasant accidents and failures. And it needs to be explained.  

Government data center projects are also becoming more relevant now and require increased attention in terms of operations: the scope of government IT systems is growing. Here, too, the development and introduction of a system of standardization and certification of sites will be required.  

When the requirements to public data centers in Russia at the level of legislation will be reduced to a standard, it can be applied to commercial data centers, including for the placement of public IT resources.  

The work in this area is ongoing, we are participating in this process in consultation with the Ministry of Digital and by building competencies for teaching courses on data center operation at the ANO Data Center. There is not much experience on such tasks in Russia, and we believe that we should share it with colleagues and clients. 

DRaaS: сценарии аварийного восстановления

BEST, money transfer and payments operator

business challenge

The customer faced a technical issue with a persistent BGP session flag with Linxdatacenter hardware. We examined the problem and found out that one of customer’s hosts was under a DDoS attack.

Because of the distributed nature of the attack, traffic couldn’t be filtered effectively, and disconnecting the host from the external network wasn’t an option. The attack stopped after changes in the server configuration, but resumed the day after. A 5.5 Gbps attack overloaded the junctions with internet providers, affecting other Linx Cloud users. To mitigate the effects of the attack, we employed a dedicated DDoS protection service.

Solution

To ensure the continuous availability of resources hosted in Linx Cloud, we rerouted all the customer’s traffic through StormWall Anti-DDoS system. The attack was stopped within half an hour. To prevent future cyberattacks, we organized all connections to the customer’s resources through the StormWall network.

client:

BEST, money transfer and payments operator

business challenge

The customer faced a technical issue with a persistent BGP session flag with Linxdatacenter hardware. We examined the problem and found out that one of customer’s hosts was under a DDoS attack.

Because of the distributed nature of the attack, traffic couldn’t be filtered effectively, and disconnecting the host from the external network wasn’t an option. The attack stopped after changes in the server configuration, but resumed the day after. A 5.5 Gbps attack overloaded the junctions with internet providers, affecting other Linx Cloud users. To mitigate the effects of the attack, we employed a dedicated DDoS protection service.

Solution

To ensure the continuous availability of resources hosted in Linx Cloud, we rerouted all the customer’s traffic through StormWall Anti-DDoS system. The attack was stopped within half an hour. To prevent future cyberattacks, we organized all connections to the customer’s resources through the StormWall network.

Thank you for your inquiry, we will get back to you shortly!