.jpg)
В ходе программы «Новая реальность ИБ» директор направления «Ростелеком-Солар» Олег Седов коснулся темы различий рисков в традиционных сервисах и внешних, облачных. Экспертом по данному вопросу выступил директор департамента М2М/IoT блока по облачным и цифровым решениям МТС Михаил Козлов.
Ссылаясь на свой большой опыт в сфере облачных технологий, Михаил Козлов заявил, что в случае внешнего сервис-провайдера добавляются два больших риска по сравнению с тем, что обычно есть внутри. Первый — несовместимость по стандартам, процессам, функциям. Второй риск — отказ в обслуживании сервис-провайдера. «Первый риск, по сути, процессная, функциональная, техническая, технологическая совместимость. Например, если я внутри использую виртуализацию на базе Microsoft или KVM. Какая платформа у провайдера? Если она другая, у меня будут сложности с тем, чтоб виртуальные машины летали взад-вперёд между сегментами. Их надо поженить. Это техническая, организационная, управленческая задача», — пояснил эксперт.
Тут же, по его словам, есть проблема, что аутсорсинг аутсорсингу рознь. Ведь существует большая разница между тем, когда берётся сайт во внешнем хостинге, и тем, когда на аутсорсинг передаётся весь ИТ-департамент, например. И есть, по сути, только два варианта: либо всё просто интегрируется, чтобы работало так, как это бы работало внутри, либо строится модель угроз, модель рисков применительно к гипотетической ситуации, что всё пойдёт не так и понадобится план Б.
Второй риск с отказом в обслуживании более многогранен. Что делать в этой ситуации? По словам Михаила Козлова, можно использовать модель сервис-провайдеров: разобрать сервис, процесс, функцию на компоненты, в которых есть какие-то SLA, связи между друг другом и посмотреть, где возможны отказы.
«В случае с облаками это бьётся на некоторые простые логические блоки. Первый — отказ на уровне данных. То есть у меня данные, например, в облаке и они потерялись — что делать? Делать бэкап, очевидно. По моему опыту, все примерно говорят одно и тоже, что услуга бэкапа из облака продаётся очень плохо, клиенты её не покупают, они за неё не платят. Почему? Теория перспектив — они считают, что бэкап никогда не понадобится. Но когда он начинает надобиться, выясняется, что бэкапа-то нет. Так как в своём большинстве бэкап предоставляется как отдельная платная услуга, за которую далеко не все платят или думают, что она включена по умолчанию в договор», — пояснил Михаил Козлов.
Второй уровень проблемы — отказ приложения. И здесь нужно просто резервировать ЦОД, резервировать сервис-провайдера.
И третий уровень — когда резервирование сервис-провайдера не помогает. Например, такое может быть когда архитектура приложения заказчика использует подход «lift and shift», то есть берётся существующее монолитное приложение и ставится в облако. При этом в архитектуре нет возможности зарезервировать сервис, например, в метрокластере, когда разные ноды приложения работают в разных ЦОДах, чтобы снять риск с точки зрения того, что если один ЦОД остановлен по какой-то причине, то ноды, работающие в другом ЦОДе, продолжают работать и на себя принимают нагрузку. «Для этого должна быть специальная архитектура, в облаке это называется клауд нейтив. Не все приложения клауд нейтив, особенно старые. И это тоже риск, который связан с архитектурой и особенностями ведения бизнеса, потому что для кого-то миллисекунда критична, а для кого-то и днями можно лежать и ничего страшного не произойдёт. Но это риск, который должен быть оценен владельцем приложения, бизнеса. И масштаб, место могут отличаться в этой истории. Но подходы все есть. Вопрос в том, что ими почему-то не все любят пользоваться», — заключил Михаил Козлов.
.png)