Современный бизнес ищет пути снижения затрат на ИТ-инфраструктуру, повышения гибкости и масштабируемости информационных систем. Одной из главных тенденций последних лет стало перемещение серверов с собственных площадок компаний на облачные платформы. Иными словами, компании рассматривают возможность перехода от собственной ИТ-инфраструктуры к IaaS (Infrastructure as a Service, инфраструктура как сервис) или даже SaaS (Software as a Service, программное обеспечение как услуга).

В этой статье эксперты компании ЦКР делятся своим взглядом на проблему миграции информационных систем в облачную инфраструктуру на примере 1С:ERP.

Безопасность информационной системы

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

Напомним, что требует закон и что нужно учитывать на практике:

Регламенты и сертификаты

В первую очередь нужно учитывать, что в системе обрабатываются персональные данные сотрудников или клиентов, а также коммерческая тайна компании — значит, информационной системе, инфраструктуре, на которой она работает, и самой компании нужно соответствовать требованиям ФЗ-152, ФСТЭК и ФСБ. И это не просто формальность, так как невыполнение требований регуляторов грозит не только утечкой чувствительных данных, но и серьезным штрафом.

В реальности это значит: провайдер облачных услуг должен быть готов к работе с ПДн (персональными данными) и иметь соответствующую документацию, у провайдера и у владельца системы должны быть задокументированы все процедуры (кто отвечает за безопасность, кто имеет доступ к данным, как ведется аудит), оборудование и программное обеспечение, на котором работает система, должны соответствовать требованиям ФСТЭК и ФСБ, особенно если речь идет о критической инфраструктуре. Поэтому прежде чем идти в облако, нужно провести элементарную проверку поставщиков услуг и программного обеспечения, запросив подтверждающие документы и уточнив наличие их в реестрах госорганов.

Контроль доступа и данных

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

Пример. В нашей практике в компании «X» бухгалтер по ошибке выгрузила отчет с ПДн клиентов и отправила его через незащищенный канал. Никто бы не заметил и не предотвратил утечку информации, если бы в компании не была настроена система DPL (Data Leak Prevention, система предотвращения утечек данных), которая отследила передачу файла с критичными тегами и заблокировала передачу информации до одобрения действия службой безопасности. Благодаря интеграции системы DLP с другими системами удалось быстро отреагировать и не допустить утечки чувствительных данных.

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

Обновления системы

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

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

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

Санкционные риски

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

Размещение информационной системы

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

Программное обеспечение как услуга

В варианте SaaS провайдер услуг предлагает «коробочное» решение с готовой облачной инфраструктурой, шаблонами под стандартные бизнес-процессы и прочими выгодами. Но в рекламируемых преимуществах использования такой инфраструктуры кроются его же и недостатки. Среди них зависимость от интернет-соединения, проблемы с которым то и дело возникают в России из-за внешнеполитической ситуации и действий регуляторов, невозможность реализовать сложные бизнес-процессы из-за ограниченности шаблонных решений, сложности с интеграцией других информационных систем компании с 1С из-за закрытости SaaS-инфраструктуры и опять же ограниченности шаблонных решений, высокая стоимость владения информационной системой с большими объемами данных и вычислений на длительный период, хранение конфиденциальных данных за периметром компании, невозможность прозрачно контролировать потоки информации на серверах, которые используются совместно с другими компаниями.

Инфраструктура как сервис

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

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

В подтверждение этих опасений мы можем рассказать интересные случаи из опыта работы наших специалистов.

Пример. В компании «U» несколько лет эксплуатировалась система «B» в локальной среде виртуализации. Пришло время продлевать расширенную поддержку на физическое оборудование, на котором основана среда виртуализации. Руководству компании «U» на очередном бизнес-семинаре эффективно подали идею облачной инфраструктуры, как очень просто мигрировать существующие сервера в облако. Хотя наши специалисты предупреждали заказчика, что архитектура приложения «как есть» не подходит для переноса в облако, что появятся проблемы с интеграцией приложений и задержками передачи данных на машины пользователей, что решение будет дороже продления контракта на поддержку оборудования, заказчик был непреклонен — очень хотелось иметь модное облако в своей инфраструктуре. В итоге было найдено компромиссное решение — построена гибридная ИТ-инфраструктура, сочетающая в себе основную часть в облаке и резервную на площадке заказчика. После миграции основных серверов системы «B», а также создания инфраструктурной обвязки в облаке заказчик получил первый счет за содержание инфраструктуры в облаке и был, мягко говоря, недоволен, проецируя эти расходы на год вперед. Это был выбор заказчика! Несмотря на это, наши специалисты совместно с представителями провайдера помогли выработать заказчику план оптимизации системы и снижения расходов.

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

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

Колокация серверов

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

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

Выводы

• Для малого бизнеса рекомендуем использовать SaaS-системы с готовыми шаблонными решениями.

• Для среднего бизнеса оптимальным вариантом является использование облачного PaaS-/IaaS-решения, где можно самостоятельно конфигурировать систему, вносить изменения в шаблоны, подстраивая систему под свои бизнес-процессы.

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

• Для крупного бизнеса, который не имеет свободных мощностей на собственной площадке, стоит обратить внимание на облачное IaaS-решение от провайдера, сертифицированного на хранение данных по требованиям ФЗ-152, ФСТЭК, ФСБ и прочих контролирующих органов.

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

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

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

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

Авторы: Виталий Бочкарев, архитектор инфраструктуры ЦКР,  Илья Никонов, архитектор ИБ ЦКР, Алексей Виноградов, функциональный архитектор ЦКР.

Источник: IT World.

Больше новостей читайте в телеграм-канале SAPLAND: Новости экосистемы.