Переносим ИТ-инфраструктуру в облака

Глобальный рынок облачных технологий постоянно растет. По оценке IDC, к 2025 году объем рынка достигнет 832,1 млрд долларов. При этом российский рынок облачных услуг будет опережать общемировой темп и к 2025 году может вырасти в 2,5 раза. Как грамотно, быстро и без ущерба для работы компании перевести ее бизнес-процессы в облако?

Вопросы для экспертов:

• Какой критерий, по-вашему, является определяющим для перехода компании в облако?
• Как правильно выбрать провайдера услуг? Какие критерии выбора облачного провайдера вы считаете важными? Как правильно выбрать тариф? Какие инструменты использовать для оценки производительности ресурсов провайдера?
• Что безопасней: приватное, гибридное или мультиоблако? Что именно вы готовы передать в облачную инфраструктуру?  Можно ли довериться публичному облаку?
• Как защититься от недобросовестного персонала облачного провайдера? Какие технологии и приемы лучше использовать? Как можно оценить профессионализм персонала облачного провайдера?
• SaaS, PaaS и IaaS... Какие сервисы лучше вынести в облако в первую очередь и какую модель использовать? Рассматриваете ли вы гибридные решения для постепенного перехода в облачную среду?
• Резервное копирование данных в облаке. Как правильно его реализовать и обезопасить свою информацию?
• Как переход в облако меняет роль внутренней ИТ-службы и службы безопасности? Риски для ИТ-специалистов при миграции корпоративных инфраструктур в облако, есть ли они? Если да, то как им противостоять?

Вопрос 1. Какой критерий, по-вашему, является определяющим для перехода компании в облако?

Павел Карнаух

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

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

Александр Гришин

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

Зачастую ущерб для компании появляется еще на этапе выбора поставщика услуг и оценки функциональности площадки – выясняется, что она не соответствует необходимым требованиям и некоторые элементы инфраструктуры не смогут работать в облачной среде. Кроме того, ошибкой становится отсутствие дальнейшего планирования использования облака. Например, реализовать сетевую абстракцию от физической инфраструктуры провайдера можно только при наличии у провайдера определенных инструментов. Такая потребность может появиться не сразу, но со временем. Также необходимо иметь возможность самостоятельной настройки виртуальной сетевой инфраструктуры без привлечения специалистов облачного провайдера. Гибкие настройки сетей потребуются для объединения облака с собственной инфраструктурой офисов, которые могут быть распределены по миру. Задача организации безопасной и надежной работы всех ресурсов компании в одной сети, вне зависимости от физического оборудования и географической распределенности, решается технологиями VXLAN и EVPN. Поэтому важно заранее убедиться, что облачные инструменты провайдера их поддерживают.

Лучше всего переносить в облако проекты с самыми высокими требования time to market и масштабирования, но при этом имеющие низкое или неизвестное время жизни. Под эти требования обычно подходят два типа проектов/процессов в компании и начинать лучше с них.

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

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

Иными словами, если компании нужна небольшая база данных, простая CMS, типичная 1С-система или небольшой kubernetes-кластер, лучше перевести их в облако – администрирование этих систем on premise выйдет компании дороже.

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

Критерий, который является определяющим для перехода компании в облако – это всегда вопрос оптимизации: если в облаке компания экономит бюджет, ресурсы и трудозатраты, – она переносит в него свои проекты. Средний и мелкий бизнес сразу начинают свой бизнес в облаках – это быстро, гибко и главное – экономит деньги. Мелкий ритейл тоже начинает всё больше работать с данными и облачными сервисами: это и онлайн-кассы, облачные 1С, системы CRM.

Владимир Ефремов

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

Вячеслав Медведев

– Переход компании в облако всегда двигают бизнес-причины. Предпосылками часто становятся, например, необходимость перевести CAPEX в OPEX, организовать точный биллинг потребляемых ресурсов и аллокацию затрат на бизнес-подразделения. Или же необходимость быстро апробировать новые сервисы, например, Machine Learning, Big Data, которые проще взять из облака, чем внедрить у себя. Еще важным мотивом выступает потребность ускорить выделение ИТ-ресурсов для разработчиков, чтобы улучшить показатель time to market. Этот стимул стал основным для Росбанка, где мы создали частное облако и сейчас развиваем его. С появлением облака показатель time to market сократился с полгода до нескольких дней, потому что выделение инфраструктурных сервисов разработчикам происходит буквально на лету.

Чистая экономия – тоже распространенный триггер для ухода в облака. Например, в проекте для крупного ритейлера мы проанализировали инфраструктуру и выделили четыре типа систем. Самые требовательные к инфраструктуре и ее надежности должны размещаться только on premise. Таких оказалось только 15 %. Остальные приложения можно было легко переразвернуть, и они не выдвигали особых требований к надежности и доступности. Поэтому их перенесли на IaaS-платформу. Т. е. в облака переселилось больше половины виртуальных машин. Получилось сэкономить 50 % бюджета на создание Active-Active кластера между двумя ЦОД.

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

Андрей Тамбовский

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

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

Насколько готова инфраструктура компании в каждом своем компоненте к такому переходу – вопрос к тем экспертам, которые обеспечивают ее работу.

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

Максим Захаренко

– Частные облака, которые представляют собой проект развертывания платформы виртуализации на собственных серверах, рассматривать не будем. Если мы говорим про облако, то речь о внешних ресурсах и сервисах. Есть несколько основных критериев выбора облака. Если компания из СМБ-сегмента, то 100 % своих информационных ресурсов имеет смысл разместить в облаке. Развертывание и дальнейшая поддержка любой собственной физической ИТ-инфраструктуры будет более громоздкой. При этом размещение такой инфраструктуры в облаке будет безопаснее со всех точек зрения. И прежде всего по сохранности данных.

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

Марис Сперга

– Приоритет на облачные технологии и услуги внешнего размещения сохраняется с 2020 года. По глобальным данным SpiceWorks, 35 % организаций либо уже перевели бизнес-процессы в облако, либо планируют ускорить этот процесс. И в качестве основных причин перехода можно выделить эластичность инфраструктуры, повышение эффективного использования ресурсов и возможность адаптировать их под бизнес-процессы. Это позволяет развивать продукты и решения с большей скоростью. К тому же предприятиям не нужно думать о покупке устройств, их размещении и обслуживании, поскольку это берут на себя облачные провайдеры. Кроме того, гарантируется высокая безопасность данных, включая защиту от киберугроз.

Александр Егоров

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

Евгений Черток

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

Дмитрий Ласьков

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

Евгений Макарьин

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

Особенно это актуально, если основной бизнес компании не связан непосредственно с ИТ. Зачем тратить время и прочие ресурсы на эту работу вместо того, чтобы сосредоточиться на основных задачах компании?

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

Руслан Косарим

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

Ольга Андреева

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

Евгений Филатов

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

Павел Коростелев

– Определяющим критерием для перехода компании в облако является информационная зрелость компании. Также можно отметить потребности в быстрых изменениях и масштабируемости.

Артем Епишин

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

Наталья Лещинец

– Если сравнивать российских провайдеров с западными, то на отечественном рынке облаков в полноценном виде почти нет. Большинство российских облачных провайдеров – это обычные серверы с виртуализацией и ограниченными сервисами, которые предоставляются в аренду клиентам. В сравнении с классическими западными провайдерами, такими как Amazon, Azure, Google, российские компании – это псевдооблака.

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

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

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

Сергей Зинкевич

– Ключевым критерием является бизнес-потребность клиента. Среди часто встречающихся мотивов:

1. Потребность в гибком масштабировании ресурсов, когда компания понимает, что текущая инфраструктура, лежащая в основе прикладных и бизнес-сервисов, не справляется с нагрузкой.
2. Желание получить оперативный доступ к современному вычислительному оборудованию без капитальных инвестиций – эта же задача пересекается с потребностью обеспечить бизнес «железом» в период кризиса полупроводников, при котором срок поставки оборудования увеличивается в несколько раз.
3. Запуск с помощью облака нового направления бизнеса или принципиально новых проектов с плохо предсказуемым спросом – финансово вкладываться в собственные системы в таких случаях экономически неоправданно.
4. Нежелание администрировать инфраструктуру. Пользуясь облачными ресурсами, клиенты снимают с себя задачу рутинной поддержки ИТ.

Иван Колегов

– Один из определяющих критериев для миграции в облако – легкость масштабирования систем. Так, компания может быстро получить дополнительные мощности, запросив их у провайдера. Среди других преимуществ клиенты особенно отмечают гибкость формата оплаты pay-as-you-go, скорость запуска облачной инфраструктуры и отсутствие капитальных затрат.

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

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

Денис Безкоровайный

– Причин перехода в облако несколько, вот основные:

1. Стоимость сервиса. Часто выгоднее приобрести уже готовое решение, чем строить его самому, привлекая дорогостоящих специалистов.
2. Полнота сервиса и перечень сопутствующих услуг. Часто к сервису провайдер услуг предлагает еще и техническую поддержку, команду реагирования на инциденты, консультации по внедрению и многое другое.
3. Часть сервисов архитектурно лучше потреблять по облачной и сервисной модели. Например, для защиты веб-приложений из-за распределенности сетевых атак гораздо удобнее использовать распределенный облачный сервис защиты с командой профессионалов, чем пытаться строить защиту у себя на базе коробочного решения.

Джимшер Чалидзе

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

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

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

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

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

Александр Лопатин

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

Михаил Бараблин

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

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

Вопрос 2. Как правильно выбрать провайдера услуг? Какие критерии выбора облачного провайдера вы считаете важными? Как правильно выбрать тариф? Какие инструменты использовать для оценки производительности ресурсов провайдера?

Андрей Тамбовский

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

Александр Гришин

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

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

Следует учесть работает ли облачный провайдер по SaaS-модели. Наличие такой возможности у поставщика позволяет ускорить time to market для своих проектов. Заказчик арендует у провайдера не виртуальный объект (машину или контейнер), на который нужно установить программное обеспечение, выполнить настройку сети и администрировать окружение, а готовый продукт. Это может быть управляемая база данных, платформа управления сайтом, среда разработки, доска для совместной работы, файловое хранилище или другое готовое решение популярных задач. Заказчик просто и быстро получает нужный ему инструмент, может сосредоточиться на решении своей задачи и не тратить ресурсы на администрирование. VMmanager – платформа для управления виртуальной инфраструктурой и построения облака – поддерживает распределенное хранилище Ceph и High availability, автоматизирует доставку сервисов клиентам по модели SaaS и предоставляет конечному пользователю возможность управлять виртуальными сетями независимо от физической сети (SDN).

Владимир Ефремов

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

Вячеслав Медведев

– Консультируя клиентов в выборе облачного провайдера, мы в первую очередь ориентируемся на полноту услуг. Иногда компаниям недостаточно классических сервисов SaaS и IaaS, нужны комплексные услуги, например, Managed Kubernetes или Managed PostgreSQL, и это определяет шорт-лист рассматриваемых провайдеров. Оказывая услугу облачного консалтинга или разрабатывая ИТ-стратегию, мы предлагаем оптимальный вариант использования облаков. Реальный кейс – крупная компания пользуется услугами двух поставщиков. Один представляет облачные сервисы на базе технологий VMware, где заказчику привычнее размещать традиционные для Enterprise нагрузки. Другой поставщик – это доступ к open source, большому меню инструментов для размещения cloud-native-приложений и разработки ПО.

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

Также не стоит забывать о соответствии законодательству в области ИБ – 152-ФЗ, стандартам Центробанка или даже регламенту GDPR Евросоюза.

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

Максим Захаренко

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

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

Если речь идет о серьезном проекте, я бы рекомендовал разместить сначала какую-то второстепенную систему в тестовом режиме на несколько месяцев. Далее на практике проверить все параметры надежности, безопасности и удобства.

Марис Сперга

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

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

Александр Егоров

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

Выбор того или иного типа облака зависит от стратегии и профиля компании. Например, ИТ-интегратору, который разрабатывает программное обеспечение, если требуется высший вендорский статус (обязательно условие – собственная лаборатория), будет комфортнее в собственном ЦОД/приватном облаке. Определяющим для ИТ-интегратора будет готовность инвестировать в разработку собственного облачного решения с планом выхода на рынок или оплачивать решения сторонних производителей. Важен фактор сертификации облачного решения.

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

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

Евгений Черток

– Принимать во внимание обязательные требования (нормативные акты, 152-ФЗ, внутрироссийское размещение и т. п.), желательные требования (удобная панель управления, невысокая стоимость, наличие между-ЦОД-ового резервирования и т. п.), прочитать отзывы, взять тестовый период. Изучить договор и дополнительные условия, там бывает много неожиданных нюансов.

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

Предоставить выбор тарифа ИТ-специалистам.

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

Дмитрий Ласьков

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

Евгений Макарьин

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

Далее: если у клиента уже есть сформировавшийся стек ИТ-решений, например, определенная платформа виртуализации, имеет смысл искать такого провайдера облаков, у которого реализован аналогичный набор ИТ-инструментов. Мигрировать с VMware на Open Stack на начальном этапе миграции в облако – не лучшая идея. Начальный этап переезда лучше производить с минимальными изменениями текущих настроек и процессов.

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

Например, постоянные ИТ-нагрузки (ВМ, приложения, которые работают 24х7х365) лучше подходят под фиксированные тарифы. За счет гарантий определенного объема потребления и/или даже предоплаты за год вперед можно получать скидки. А вот «плавающие» нагрузки, которые динамически меняются в течение дня или другого периода, как правило, лучше оплачивать по модели pay-as-you-go.

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

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

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

Это оптимальный сценарий любой миграции сегодня.

Руслан Косарим

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

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

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

Ольга Андреева

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

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

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

И если по этим критериям вам подходит какой-то провайдер, то следует выяснить перед подписанием договора очень важные для совместной работы данные о выбранном облачном провайдере:
1) Имеется ли у провайдера контракты на обслуживание инженерных систем и их поддержку при наступлении аварийной ситуации, ведь отсутствие электропитания или недостаток дизельного топлива у генератора напрямую скажутся на работе всех сдаваемых в аренду систем.
2) Наличие юридического оформления на использование зданий, включая права собственности и разрешения различных государственных инстанций.
3) Защищенность ЦОД от природных аномалий (температура, влажность и т. д.).
4) Наличие проекта на построение/модернизацию ЦОД и актуализированной документации.

Евгений Филатов

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

1. Нужно посмотреть на список сервисов, которые предоставляет провайдер. Основная польза использования облаков в PaaS-сервисах, обеспечивающих быструю разработку новых ИТ-услуг, и SaaS – уже готовых приложений, которые можно использовать по подписке. И только потом уже важны IaaS, а именно они максимально широко представлены у большинства провайдеров. Соответственно, выбор провайдера должен начинаться с взгляда на собственную повестку развития бизнеса, определения целевого ИТ-ландшафта и уже под него выбирать провайдеров услуг по наличию тех сервисов, которые будут применимы.
2. Оценить надежность сервисов провайдера и возможность обеспечения на его (или их) ресурсах целевых требований по доступности услуг. На текущий момент существует точка зрения, что облачные провайдеры не могут обеспечить достаточной надежности сервисов. Некоторое время назад это было близко к истине, но сегодня уже переходит в разряд мифов. Реальная статистика сбоев и отказов демонстрирует даже большую надежность облачных сервисов по сравнению с собственными ИТ-системами и ЦОД. Естественно, данный факт не отменяет необходимости в планировании правильной архитектуры решений на базе облачных сервисов, а также хорошо выстроенных процессов эксплуатации. Облако не панацея, но очень хороший инструмент.
3. Оценить возможности провайдера обеспечить требования информационной безопасности. В некоторой части требований провайдер должен быть сертифицирован соответствующими организациями, в некоторой части может предоставить средства обеспечения ИБ так же, «как сервис», а по части специфических требований в облаке придется выстраивать систему защиты аналогично той, которая реализуется в собственном периметре.

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

Павел Коростелев

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

Артем Епишин

– В первую очередь необходимо проверить, что провайдер обладает всеми необходимыми лицензиями на осуществление своей деятельности, а также соответствует стандартам и законам, которые необходимы в вашей сфере деятельности. Например, это могут быть PCI DSS, 152-ФЗ. Обязательно наличие SLA, т. е. документа, который гарантирует скорость реагирования на инциденты, ответов на вопросы в поддержку, времени выполнения работ, процент доступности сервисов провайдера и т. д.

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

Наталья Лещинец

– Выбор провайдера – индивидуальный вопрос для каждой компании и внутренних стандартов. Немаловажный фактор – ПО и тип виртуализации, которые используют провайдер, и корпоративные стандарты компании – OpenSource (Red Hat KVM, OpenStack) или проприетарные (VMware, Microsoft).

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

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

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

Еще один критерий – что и как прописано в SLA и применяемые меры защиты от DDoS-атак и киберугроз. Как правило, у всех пользователей в инфраструктуре облачного провайдера общие каналы управления и Интернета. Если под действия злоумышленников попадает даже один клиент, это может сказаться на производительности, доступности и отказоустойчивости облака для всех остальных пользователей. Важно понимать, как будет действовать провайдер в этом случае.

Сергей Зинкевич

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

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

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

Денис Безкоровайный

– Это зависит от того, о какой модели облачных услуг идет речь. Например, тестировать производительность SaaS-сервиса крайне сложно, а вот для IaaS производительность платформы может действительно быть важным критерием. Также среди важных критериев выбора облачного провайдера можно выделить наличие готовых API для управления ресурсами и биллинга, выгрузки статистики и по использованию ресурсов, и по стоимости, а также серьезное отношение к безопасности – готовность провайдера подтвердить свои заверения в области информационной безопасности независимыми аудитами и открытость сведений о применяемых мерах защиты.

Иван Колегов

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

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

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

Также при выборе облачного провайдера нужно уточнить, где расположены дата-центры. Это важно для соответствия используемых способов обработки и хранения данных локальным нормативным правовым актам. Необходимо внимательно изучить SLA (Service Level Agreement) на предоставляемую услугу: что является компенсируемым простоем, какой заявленный уровень SLA, какие выплаты возможны в случае простоя сервиса.

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

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

Если говорить о том, какие инструменты используют для оценки производительности ресурсов провайдера, то здесь можно упомянуть FIO – тестирование производительности дисковой системы. Если используете 1С, то запускайте «Тест Гилева». В целом, я бы рекомендовал не пользоваться синтетическими бенчмарками, а попытаться развернуть прикладную нагрузку и уже на ней тестировать.

Джимшер Чалидзе

– Так как использование облаков одна из частей комплексной цифровой трансформации, то надо помнить, что кровь цифры – данные. И очень важно смотреть, готов ли провайдер делиться вашими данными с вами или нет. Это очень актуально для SaaS-решений.

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

Что касается тарифов – надо садиться и считать. А что вам-то нужно? Чем будете пользоваться? Каков сценарий? Далее вопрос технических расчетов и ваших приоритетов. Готовы немного переплатить за скорость и надежность, или этот сервис не критичен и можно сэкономить?

Александр Лопатин

– При выборе провайдера услуг важно, чтобы у него были собственные развитые ЦОД с современным оснащением (желательно географически разнесенных с возможностью синхронизации и быстрого переноса данных). Доступность этих серверов должна быть 99 % и выше. Необходим полный спектр облачных технологий IaaS, PaaS, SaaS. Если облако публичное, а ваша компания очень гибкая по потреблению ресурсов, то лучше выбирать тарифный план с поминутной/посекундной оплатой. Можно дополнительно сэкономить на ресурсах и использовать их только тогда, когда они необходимы.

Михаил Бараблин

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

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

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

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

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

Александр Гришин

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

Можно ли довериться публичному облаку?

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

Павел Карнаух

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

Владимир Ефремов

– Всё зависит не от технологии облака как такового, а от средств защиты и команды ИБ-специалистов, которые обслуживают эти средства защиты. Атакам подвержены все инфраструктуры, эксплуатируемые уязвимости есть абсолютно всегда, даже если вы о них не знаете. Поэтому безопаснее не приватное или гибридное облако, безопаснее правильное облако, безопаснее то облако, команде обеспечения которого вы доверяете. Если говорить о публичных облаках, то здесь есть вполне конкретные показатели безопасности – сертификаты соответствия. Хранить гостайну на публичных облаках мы бы не рекомендовали, но если у публичного облака есть сертификаты соответствия PCI DSS, пройдена сертификация по 152-ФЗ, используются меры приказа 21 ФСТЭК, то (при наличии шифрованного канала связи) вы можете быть уверены, что публичное облако ничем не хуже приватного и требует меньше затрат на использование.

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

Вячеслав Медведев

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

В то же время публичные облака сейчас по защищенности достигли высокого уровня. Они централизованно обеспечивают безопасность своей ИТ-инфраструктуры с помощью лучших практик: операционные системы регулярно обновляются, сеть построена для одновременного безопасного размещения многих заказчиков. Почти все провайдеры предлагают услуги по обеспечению ИБ размещаемых нагрузок: сетевая изоляция, антивирус, IDS, анти-DDoS, WAF, шифрование данных, решения по безопасному хранению секретов. Некоторые начали использовать аппаратный модули HSM для хранения ключей при шифровании данных в S3-хранилище. Такой уровень защиты можно встретить только лишь в инфраструктуре крупной компании с сильной службой ИБ.

Андрей Тамбовский

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

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

Заказчик же должен четко понимать, где проходит разграничение зоны ответственности – за что отвечает его облачный провайдер, а о чем заказчик должен позаботиться сам. Всё-таки чаще всего, когда говорят об облачных сервисах, имеют в виду сервисы уровня IaaS. Т. е. всё, что гарантирует провайдер, ограничивается уровнем аппаратных средств, доступом к управлению виртуальными машинами. Думать же о том, как будет выстроена защита доступа к приложениям и данным, должен сам заказчик.

Максим Захаренко

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

Марис Сперга

– При размещении данных у себя в частном облаке или у провайдера в публичном стоит заботиться о безопасности либо самостоятельно, либо договариваться об этом с поставщиком услуг. До тех пор, пока меры безопасности предприняты не будут, ваша инфраструктура не будет защищена в обоих случаях. Облачные провайдеры предлагают различные услуги по кибербезопасности – от защиты от DDoS-атак и SIEM, до полного управления ИТ-безопасностью (Security operations center) в случае Tet, например.

Несмотря на то, что услуги публичных облаков стремительно растут, часть ИТ-инфраструктуры предприятий всё равно останется в офисах клиентов (наземная инфраструктура). Поскольку не все системы можно перенести в облако как с технологической точки зрения, так и правовой (требования законодательства), поэтому будущее за гибридными облачными решениями. Благодаря им технологически сложные и не особо растущие системы можно оставить «у себя», а те, что не привязаны к инфраструктуре офиса, перенести в облако и использовать эластичную модель pay-as-you-go. Гибридное облако позволяет подстроить инфраструктуру под потребности предприятия в конкретный момент, а не наоборот. Также более востребованным становится подход «мультиоблака» (multicloud), когда для обеспечения необходимой предприятию инфраструктуры используются несколько публичных облаков. Такая модель расширяет возможности бизнеса как с точки зрения инфраструктуры и ее мощности, так и доступности разных систем или приложений.

За последние четыре года мы наблюдаем следующую тенденцию – клиенты, которые разместили частные облака в наших центрах обработки данных, всё чаще просят интегрировать их в публичные облака. Это обеспечивает как более быстрые сроки получения дополнительных ресурсов, так и гарантирует предприятиям мобильность без инвестиций в ИТ-инфраструктуру. Например, в прошлом году около 30 % крупных клиентов, которые разместили у нас частные облака, приняли решение соединить их с нашей же публичной платформой Tet Cloud, чтобы получить все доступные преимущества.

Александр Егоров

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

Евгений Черток

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

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

Любое публичное облако (рано или поздно): ломается, сгорает, теряет данные или неожиданно меняет тарифы, банкротится и т. п.

Дмитрий Ласьков

– Безопасно хранить данные в собственной инфраструктуре при условии, что в безопасность вложены большие деньги. Если на безопасность и инфраструктуру денег нет, можно все или часть данных перенести в надежный ЦОД. Приватные облака часто используют крупные корпоративные игроки, которые хотят обеспечить полный контроль над своей безопасностью. Иные компании выстраивают гибридные облака, часть сервисов выносятся из внутренней инфраструктуры в ЦОД. А если компания совсем маленькая, например, стартап, удобнее всего всю инфраструктуру развернуть у одного сервис-провайдера. Для каждой компании набор сервисов для передачи в ЦОД свой, тут большую роль играет размер и тип бизнеса. Публичное облако по своей природе наименее защищено, доверять, конечно, можно, но не критически важные для бизнеса данные.

Евгений Макарьин

– Конечно, самый безопасный вариант – собственное частное облако, полностью изолированное от других клиентов на уровне не только серверов, но и СХД и сетевой части.

Что касается гибридных и мультиоблачных схем, то тут подход case by case, когда клиент и ИБ-специалисты с его стороны совместно с персоналом провайдера садятся и составляют конфигурацию проекта размещения, определяя, какие ИТ-системы позволяют применять тот или иной сценарий размещения в публичном облаке и на каких условиях.

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

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

Руслан Косарим

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

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

В случаях с публичным и гибридным облаками очень важно помнить о том, что происходит разделение ответственности. Облачный провайдер отвечает за безопасность инфраструктуры, предоставляемой клиентам как сервис. Но всё, что находится «выше» этой инфраструктуры, попадает в зону ответственности компании-клиента. Чем «выше» уровень сервиса, тем больше ответственности на стороне провайдера. Например, охват ответственности облачного провайдера с точки зрения безопасности в инфраструктуре как сервис (IaaS) ниже, чем в программном обеспечении как сервисе (SaaS).

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

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

Евгений Филатов

– Полностью публичное облако с полным отказом от собственной инфраструктуры – это, скорее, вырожденный случай «сферической компании в вакууме и ее сферического бизнеса». Такие примеры существуют, но это либо очень маленький бизнес, либо полная передача части функций по управлению ИТ-инфраструктурой облачному провайдеру. Если брать более-менее крупную компанию в реальном мире, часть функций можно перенести в облако, а часть унаследованных систем останутся во внутреннем периметре. Это будет в том или ином виде всё равно гибрид. Ключевой вопрос, насколько приватная часть станет приватным облаком, т. е. насколько оно будет автоматизировано с точки зрения управления ресурсами (и их биллинга), насколько бесшовно можно будет перемещать нагрузку между облаками. Построение и дальнейшее развитие частного облака – задача очень нетривиальная и требующая значительных финансовых и трудозатрат. Кроме того, часть функций вообще нельзя передать в облако, например, это SCADA и частично MES-системы, которые должны размещаться в непосредственной близости к оборудованию. Обеспечение же безопасности – процесс сквозной и не зависящий от того, где размещаются системы. Подход по обеспечению ИБ только за счет защиты периметра устарел и перестал работать более 10 лет назад.

Павел Коростелев

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

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

Артем Епишин

– Из самого определения приватного облака следует, что формально оно является более безопасным, так как ресурсы принадлежат одной компании и не делятся провайдером между клиентами. Но с развитием облачных технологий это уже не так однозначно, провайдеры развивают публичные облака, накапливают экспертизу, занимаются вопросами безопасности и аварийного восстановления данных, условно говоря, 24/7, что может в некоторых случаях быть более безопасным, чем приватное облако при сравнимых затратах на их поддержание.

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

Наталья Лещинец

– Ни одно облако не может гарантировать полную безопасность данных. Даже если компания пользуется приватным облаком от провайдера, она не может контролировать действия администраторов на 100 %. А если нет полного контроля, нет и безопасности.

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

Сергей Зинкевич

– У каждой из предложенных моделей есть свои плюсы и минусы. Утверждать, что некое приватное облако безопасней публичного, нельзя, так как нужно знать, как именно это облако было построено и как оно эксплуатируется. Для провайдера облако – это core business, любой сбой – потеря репутации и серьезные штрафы, поэтому инфраструктура здесь обновляется значительно чаще (в среднем жизненный цикл оборудования не 3–5 лет, как в on premise-инфраструктуре, а порядка 2 лет). Также чаще проводятся пен-тесты: Облако КРОК на предмет уязвимостей проверяют два раза в год.

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

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

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

Денис Безкоровайный

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

Иван Колегов

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

Однако стоит уточнить: убеждение, что публичное облако – небезопасное решение – уже давно неактуально. Сейчас многие крупные игроки рынка, в том числе Selectel, привели свои облачные инфраструктуры в соответствие с 152-ФЗ и другими нормативными актами, например, PCI DSS. Это означает, что в публичных облаках уже встроены и реализованы требования по информационной безопасности.

Джимшер Чалидзе

– Безопаснее всего, конечно, приватное. Но насколько вам нужна безопасность? И сколько вы готовы за нее платить? Я считаю, что наиболее подходящий компромисс – гибрид. Критичные данные в приватном облаке. Остальные – в публичном.

Александр Лопатин

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

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

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

Михаил Бараблин

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

 

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

Александр Гришин

– Можно провести аудит, как внешний, так и внутренний, с анализом документации провайдера. Он поможет убедиться, что поставщик услуг внедрил необходимые процедуры безопасности, прошел аттестацию по требованиям регулятора сегмента, соответствует рекомендациям CSA CAIQ. Если говорить о недобросовестности персонала, то такие же риски могут существовать и на стороне клиента.

Владимир Ефремов

– Современные средства защиты позволяют защититься от потенциальных действий недобросовестного персонала облачного провайдера, связанных с попытками перехвата административного доступа, компрометации репозиториев, компрометации виртуальных серверов, копирования данных. Строго говоря, вы должны делать всё то же самое, что и при использовании собственной виртуальной инфраструктуры, ведь от злонамеренных действий собственных администраторов тоже нужно быть защищенным: используйте шифрование чувствительной информации и ее резервных копий, используйте средства управления административным доступом, используйте True SSO и IdM-решения. Прежде всего подумайте о минимально возможном составе административного доступа со стороны персонала облачного провайдера и требуйте соблюдения этого обстоятельства – на время аренды ресурсов провайдер обязан обеспечить конфиденциальность, целостность и доступность. Формула качественной защиты не меняется.

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

Андрей Тамбовский

– Надо понимать, что серьезные провайдеры облачных сервисов озабочены качеством своего персонала, может быть, даже больше, чем их заказчики. Стоит исходить из того, что персонал, обеспечивающий работу ЦОД провайдера, как минимум, не заинтересован в том, чтобы что-то случилось с оборудованием, которое он обслуживает, при этом существует разграничение прав доступа персонала к данным. Да и как найти данные, скажем, компании Х, когда ее серверы – это виртуальные машины, работающие на большом пуле одинаковых аппаратных серверов, а для данных выделен том на системе хранения класса mid-range? Просто так подойти и вынуть диск, чтобы унести чужие данные, не получится.

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

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

Максим Захаренко

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

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

Марис Сперга

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

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

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

Александр Егоров

– Помимо юридических и административных мер, следует использовать технические решения для контроля доступа персонала ко всем инфраструктурным элементам ЦОД, облака. Для контроля работы с серверным ПО есть решения типа balabit shell control box.

Значительно большую угрозу сохранности данных предоставляет сотрудник компании. Облачные решения в вопросе обеспечения безопасности достаточно продвинуты.

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

Оценить профессионализм персонала облачного провайдера можно по уровням сертификации. Можно попробовать запросить для оценки базу тикетов/инцидентов и описание регламентных работ на инфраструктуре облака. Наличие документации и фиксации тикетов/инцидентов, а также методики управления проблемами/сервисами даст представление об уровне зрелости процессов в провайдере. Наличие уровня зрелости 4+ – это косвенный показатель профессионализма.

Евгений Черток

– Никак. Не хранить в облаке ничего такого, что нельзя было бы опубликовать для всех в СМИ, на фейсбуке и т. п.

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

Убедиться в профессионализме можно только косвенно по долгой незапятнанной истории провайдера. Читать на фейсбуке истории о провайдере и в блогах отзывы пользователей.

Дмитрий Ласьков

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

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

Евгений Макарьин

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

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

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

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

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

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

Руслан Косарим

– В Европе или США облаку достаточно обладать определенными сертификатами, подтверждающими надлежащий уровень безопасности и надежности хранения данных клиентов, и потребители относятся к этому подтверждению с высоким уровнем доверия. В России на текущий момент компании испытывают скепсис по поводу доверия к облачному провайдеру.

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

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

Ольга Андреева

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

Евгений Филатов

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

Павел Коростелев

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

Артем Епишин

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

Наталья Лещинец

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

Сергей Зинкевич

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

Как утверждают в «Касперском», в 9 из 10 случае утечек из облака виноват человеческий фактор, а именно – недостаточное внимание специалистов заказчика к вопросу защиты данных. Распространенными ошибками являются: открытые порты, оставленные администраторами; использование некриптостойких паролей к учеткам в облаке; отказ от маскирования данных (когда для целей тестирования программных продуктов используются не фиктивные, а реальные данные). Внимательность и следование правилам защищенной работы в облаке позволяют свести количество инцидентов к нулю.

Денис Безкоровайный

– Современные облачные провайдеры предлагают множество готовых решений, например, шифрование данных, управление ключами, даже хранение ключей в аппаратных HSM-модулях. Важно строить свою инфраструктуру и приложения таким образом, чтобы компрометация одного из приложений/сервисов не вела к компрометации всей инфраструктуры. Т. е. уже сейчас современные практики разработки и эксплуатации исходят из того, что злоумышленник может быть даже внутри организации. В такой парадигме неважно, где будет запущена инфраструктура или приложение – у себя в дата-центре или в облаке провайдера. Часто сотрудники провайдера не имеют и не должны иметь доступ к логической структуре данных и приложений, а физический доступ сотрудников провайдера к жестким дискам в дата-центре, обслуживающем облачную инфраструктуру, ничего не даст, так как данные хранятся на дисках в зашифрованном виде.

Иван Колегов

– У крупных провайдеров есть внутренние регламенты, средства по контролю и не допущению ошибок, которые должны соответствовать 152-ФЗ и другим нормативными актам. Отсутствие документов, подтверждающих это соответствие, и может стать показателем недобросовестности провайдера.

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

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

Александр Лопатин

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

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

Джимшер Чалидзе

– По репутации на рынке. В конечном счете все внутренние проблемы отображаются в качестве сервиса и на лояльности клиентов. Также смотрите на то, сколько клиентов у провайдера уже больше года. Если сервис неудовлетворителен – вряд ли кто-то будет продлевать договор.

Михаил Бараблин

– Решения известны, вопрос в том, применяете вы их или нет. Различные SIEM, шифрование систем хранения, шифрование трафика, соблюдение методологий DevSecOps при разработке – все это не новость. Вопрос в том, достаточно ли вы вложились в соблюдение «гигиены» информационной безопасности при разработке или размещении решений. Я считаю, что при переходе в облака стоит обзавестись своим специалистом по ИБ или прибегнуть к аудиту решений.

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

 

Вопрос 5. SaaS, PaaS и IaaS... Какие сервисы лучше вынести в облако в первую очередь и какую модель использовать? Рассматриваете ли вы гибридные решения для постепенного перехода в облачную среду?

Александр Гришин

– IaaS – это инфраструктура как сервис, вычислительные ресурсы в аренду. Фактически позволяет не строить собственную серверную, но подразумевает наличие персонала с определенными компетенциями: администрирования объектов виртуализации, операционных систем (Админ windows/linux), сетей (сетевик), резервного копирования, мониторинга инфраструктуры и администрирование ПО, которое будет решать задачи компании.

PaaS – это платформа как сервис. Ее использование позволяет забыть про «нижний» уровень инфраструктуры, облачный провайдер забирает на себя первых 5 специалистов. На стороне компании остаются задачи администрирования ПО, которые может решать DevOps-инженер, и собственные задачи бизнеса, которые решает разработчик, пишущий заказчику софт.

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

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

SaaS больше про понятные простые задачи – клиенту нужен документооборот, CRM-система или CMS для сайта и выполняться будет простая и понятная работа.

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

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

Павел Карнаух

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

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

Будь то переход в частное или публичное облако, большинство пользователей начинают с новых приложений, разработанных в микросервисной архитектуре. Веб-приложения и приложения для заказчиков также хорошо ложатся в облачную модель. Офисные, почтовые системы и системы CRM – первые кандидаты на перевод в SaaS-модель. Для традиционных некритичных рабочих нагрузок, как правило, хорошо подходит модель IaaS. А вот с тяжелыми критически важными приложениями, предъявляющими особые требования к производительности и задержкам, с жестко связанными сложными унаследованными системами и т. п. нужно быть очень аккуратными – возможно, облако для них не лучший вариант.

Владимир Ефремов

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

Вячеслав Медведев

– В мире Enterprise в первую очередь в облако выносятся те сервисы, которые требуют высокой скорости выделения ресурсов, а выбор формы облачных услуг вторичен. Обычно это IaaS или PaaS, но может быть и SaaS. Такая концепция близка крупным компаниям, потому что у них есть собственные ИТ-команды и они не так ограничены в ресурсах. В сегменте SMB заказчики чаще выбирают SaaS-предложения.

Андрей Тамбовский

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

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

Максим Захаренко

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

Нет однозначной рекомендации, какого уровня сервис лучше взять и какие ресурсы мигрировать в облако. В целом публичные ресурсы, коммуникационные сервисы (сайты, электронная почта, helpdesk-системы) имеет смысл первыми разместить в надежном месте на быстром гарантированном канале, т. е. в облаке. Далее внутренние учетные и офисные системы. Особенно, если компания, например, московская, поняла эффективность удаленной работы сотрудников из регионов. А вот АСУ ТП, используемые в управлении технологическими процессам, не стоит переносить в облако. Зато их накопленные данные для анализа с целью повышения эффективности – только в облако.

Марис Сперга

– В случае IaaS и PaaS – для больших предприятий это среда с инфраструктурой, которая обеспечивает гибкость. Такая среда позволяет создать и дешевле содержать среду для тестирования и разработки (test&development), а также подстраивать ресурсы под сезонность бизнеса. Однако в последние годы мы видим, что малый и средний бизнес стали использовать IaaS как основную инфраструктуру, поскольку им выгоднее получить необходимые ресурсы от провайдера, чем самим покупать, настраивать и поддерживать. Модель SaaS больше подходит для компаний, которые предоставляют услуги своим конечным пользователям удаленно, т. е. без инсталляции на устройства клиентов.

Александр Егоров

– Офисные сервисы, которые не являются критичными для функционирования компании. SaaS. Если ИТ-интегратору неэффективно наращивать ресурсы своего облака, например, для разовой демонстрации или проверки прототипа нового ПО – PaaS. IaaS имеет смысл рассматривать при наличие собственного ИТ и стратегии, которая включает, например, сокращение CAPEX на серверное оборудование/облачные лицензии. Мы рассматриваем и активно используем для обеспечения разработки/выпуска программного обеспечения Bare Metal Servers, OKD и облачную платформу, в основе которой доработанный OpenStack.

Дмитрий Ласьков

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

• если вашему бизнесу требуется готовое программное обеспечение (CRM, электронная почта, инструменты для совместной работы и т. д.), выберите «Программное обеспечение в качестве услуги» (SaaS);
• если вашей компании требуется платформа для создания программных продуктов, выберите «Платформу в качестве услуги» (PaaS);
• если вашему бизнесу нужна виртуальные серверы и машины, выберите «Инфраструктуру в качестве службы» (IaaS).

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

Евгений Макарьин

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

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

Руслан Косарим

– Чаще всего IaaS/PaaS используется для реализации ключевых бизнес-сервисов компании. Если приложение позволяет зарабатывать, то компания должна иметь возможность изменять, дорабатывать и улучшать сервис, что становится возможным при использовании IaaS/PaaS, когда провайдер не имеет доступа к бизнес-логике самого приложения.

SaaS чаще выбирается для вспомогательных процессов, там, где можно снизить расходы на поддержание сервиса, доверив вопросы надежности и безопасности провайдеру. Примером таких сервисов становятся и услуги по безопасности (Security as a Service). Для среднего и малого бизнеса с небольшим штатом сотрудников безопасности услуги по ИБ в формате сервиса представляются отличным экономным вариантом, позволяющим минимизировать расходы на безопасность, при этом повышая ее уровень.

Павел Коростелев

– PaaS и IaaS постепенно выходят из моды. Вообще выбор модели зависит от уровня зрелости компании и понятия для чего мы собираемся использовать облака. Опять же готовых рецептов нет, и каждая компания решает за себя. Если мы говорим про гибрид, то в целом это хорошая стратегия. Но важно понимать, что переход будет проходить поэтапно. Сначала мы в публичное облако отдаем так называемый test-dev – дамп информации без реальных данных, созданный специально для теста. Далее передаются специфические сервисы, которые облачный провайдер будет реализовывать лучше, чем собственная ИТ-инфраструктура. Например, сервисы управления базами данных, контейнерами или аналитикой с использованием ИИ. Потом наступает очередь «переезда» бизнес-подразделений с конкретными для них приложениями. Последним этапом становится задача переноса ядерных бизнес-систем в облако.

Артем Епишин

– Для нас, как компании-разработчика, подходит модель IaaS, по которой мы получаем виртуальные машины с определенными ресурсами и самостоятельно реализуем на их основе необходимые нам сервисы, предоставляя их нашим конечным клиентам, как раз по SaaS-модели.

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

Наталья Лещинец

– Какой сервис выносить в облако каждая компания решает самостоятельно. Всё зависит от потребностей, а ориентироваться можно на экономическую эффективность, критичность потери данных и доступность провайдера. Например, чтобы протестировать новый продукт для разработчиков, разумнее использовать облако и вынести туда IaaS. Это выгоднее, чем тратить капитальные ресурсы на инфраструктуру, к которой не предъявляются специализированные требования.

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

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

Сергей Зинкевич

– SaaS и PaaS – удобные и часто экономичные сервисы, которые востребованы в первую очередь компаниями из малого и среднего бизнеса. Крупным клиентам, как правило, эти облачные продукты не подходят, так как им нужна кастомизация, дополнительный функционал, консультации по работе сервисов в конце концов. Один из примеров Kubernetes as a Service. Продукт из коробки для развертывания кластеров Kubernetes кажется подходящим решением, если нет своих специалистов, либо их квалификация вызывает вопросы. Но как только всплывают новые вводные – например, когда нужно внедрить CNI-плагин, отличный от того, что предлагает облачный провайдер, или когда необходимо настроить внутренние потоки трафика через узел информационной безопасности – одного PaaS становится недостаточно. В таких случаях лучше пользоваться услугой Managed Kubernetes.

IaaS применяется крупными корпоративными клиентами значительно чаще. На базе публичной инфраструктуры они строят резервные ЦОД, обеспечивают производительную работу e-commerce и финансовых приложений, тестируют, разрабатывают и запускают новые продукты и бизнесы. Однако к миграции в публичное облако нужно подходить обдуманно. Если для бизнес-сервиса не характерна динамичная, меняющаяся со временем нагрузка, его лучше разместить в выделенной инфраструктуре дата-центра. Это будет выгоднее по всем параметрам. Гибридные схемы, учитывающие публичное облако, аренду выделенного оборудования в ЦОД, on premise инфраструктуру и отдельные SaaS- и PaaS-сервисы, хороши для сложной, разнородной среды с большим количеством приложений.

Денис Безкоровайный

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

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

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

Иван Колегов

– Для быстрого и безболезненного переезда в облако существуют cloud-native-сервисы, которые уже полностью готовы к переносу и строятся на базе микросервисной архитектуры, используя контейнеры, CI/CD и DevOPS-практики. Внедрение таких сервисов позволяет быстро масштабироваться и получать максимальную выгоду от облачной инфраструктуры.

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

Гибридизация – это самый оптимальный вариант для постепенного перехода в облачную среду. Согласно нашей статистике, большинство клиентов Selectel используют именно гибридную инфраструктуру. Т. е. какая-то часть их legacy размещается в IaaS, на выделенных серверах, а какие-то новые проекты они стараются запускать в платформенных сервисах: Kubernetes как сервис, DBaaS.

Джимшер Чалидзе

– Модель использования зависит от масштаба бизнеса. Для малого и среднего бизнеса актуальнее SaaS и PaaS. Это позволит эффективнее использовать имеющиеся ресурсы и быстрее развиваться.

Для среднего и крупного бизнеса имеет смысл рассмотреть IaaS и PaaS. Так вы сможете сэкономить на эффекте масштаба. Это уже будет иметь экономический смысл. Кроме того, вы сможете лучше и гибче реализовывать политики по информационной безопасности и т. п.

Александр Лопатин

– Первым конечно же необходимо выносить SaaS-решения – они очень гибкие и легко развертываются с минимальными трудозатратами. Гибридная схема подключения между облаком и оn premise помогает минимизировать риски при миграции, уменьшить даунтайм сервиса при миграции. Всегда можно прекратить подписку, если переход в облако не оправдал ожиданий. Классическим примером может быть миграция Exchange-M365, SCCM-Intune, SCVMM-Azure и т. д.

Михаил Бараблин

– На мой взгляд, нужно начинать с уровня инфраструктуры и постепенно переносить остальные, более сложные уровни в такой последовательности: IaaS, PaaS и затем уже полноценные SaaS-решения. Но тут простор для вариаций огромный, нужно смотреть на ИТ-ландшафт конкретного предприятия. Однозначного ответа «для всех» тут нет.

 

Вопрос 6. Резервное копирование данных в облаке. Как правильно его реализовать и обезопасить свою информацию?

Павел Карнаух

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

Затем нужно определиться: устраивает ли вас функциональность решения, предоставляемого сервис-провайдером? Если нет, то, как правило, есть возможность создать собственную службу резервного копирования в облаке или подключиться к онлайн-сервису резервного копирования – соответствующие решения предлагают различные вендоры, в том числе и Dell Technologies.

Евгений Черток

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

Владимир Ефремов

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

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

Вячеслав Медведев

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

Если же планируется использование резервного копирования своей инфраструктуры в облако, то обязательно нужно смотреть на весь процесс резервирования в комплексе, учитывая взаимодействие локальных систем и облачного хранилища. Пример из жизни: компания хотела отправить в облако бэкапы одной системы. Цена за объем хранимых данных была приемлемая, сделка казалась привлекательной. Но при тестировании мы обнаружили: чтобы потом этими бэкапами воспользоваться для восстановления, нужно в 2-3 раза больше времени, чем это допустимо для заказчика. По рекомендованному провайдером тарифу канал облака оказался недостаточно производительным. А если использовать более производительный канал, то стоимость услуги увеличивалась и уже не подходила компании по бюджету.

Максим Захаренко

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

Марис Сперга

– Резервное копирование в облаке существует давно, но важно понимать, что именно вы хотите разместить и какими услугами пользоваться: размещать ли файлы как FTP, иметь ли возможность восстановить данные в случае аварии или же создать полноценный DRS site в облаке. Стоит решить, насколько быстрым должен быть план восстановления или же предусмотреть, что в случае аварии часть инфраструктуры работает из резервного дата-центра, который находится в облаке. Есть множество решений, обеспечивающих эту функциональность, как, например VEEAM BaaS или VEEA DraaS.

Александр Егоров

– Резервное копирование является одним из обязательных сервисов современных облаков. Переходить в облако можно только при наличии сервисов резервирования. Для определения порядка резервирования сервисов требуется определиться с параметрами RPO|RTO – допустимым временем потери данных и временем простоя. Может потребоваться облако, распределенное в нескольких ЦОД, – это необходимая катастрофоустойчивость.

Дмитрий Ласьков

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

Евгений Макарьин

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

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

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

Руслан Косарим

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

В случае с IaaS/PaaS провайдер отвечает за резервирование инфраструктурной прослойки. Клиент облака – за резервные копии данных и конфигурации приложений, а также за их безопасное хранение. Если приложение вышло из строя и нет резервной копии данных, но при этом облачная инфраструктура была доступна 24/7 без сбоев – здесь очевидна ответственность клиента и владельца сервиса внутри этой компании.

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

Ольга Андреева

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

Если все вычисления уже перенесены в облако, то ответственность за резервное копирование обычно берет на себя провайдер облачных сервисов. Но зачастую он не берет на себя ответственность за восстановление данных. При схеме PaaS и IaaS собственные виртуальные машины заказчику потребуется восстановить самостоятельно.

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

Механизм обеспечения безопасного хранения заложен в возможностях приложений резервного копирования. Для хранения в облаке подходят только зашифрованные копии. Кроме того, у современных средств резервного копирования обычно имеется опция копирования в облако (например, у Veeam®, Commvault®, Acronis Infoprotect). Остается только выбрать провайдера и настроить.

Евгений Филатов

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

Павел Коростелев

– Резервное копирование данных в облаке – достаточно частое явление, чтобы сэкономить средства на постройке собственного ЦОД. Однако его реализация зависит от конкретного процесса резервного копирования в приложении. Узнав требования к нему, можно сравнить с возможностями облачного провайдера и понять возможность выполнения задачи.

Артем Епишин

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

Наталья Лещинец

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

Сергей Зинкевич

– Главное правило – использовать в принципе резервное копирование, а ему следуют не все клиенты. По умолчанию к резервному копированию прибегают 80 % облачных клиентов. При выборе решения нужно ориентироваться на программный продукт, который предлагается провайдером, а также на инфраструктуру, в которой бэкапы хранятся. Например, у нас организовано хранение резервных копий в S3 (объектное хранилище для неструктурированного контента), которое распределено на три облачных ЦОД. Следовательно, в каждом из них лежит по одной копии бэкапа. Таким образом обеспечивается дополнительная защита данных от потери.

Иван Колегов

– Большинство крупных провайдеров предоставляют услугу резервного копирования «из коробки». В нашем случае – это Self-Service Portal, где клиент сам может выбрать объекты и правила резервного копирования, которые им необходимы. Также он может проводить периодическое тестирование резервных копий. Это применимо как к облачным сервисам, так и к выделенным серверам.

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

Александр Лопатин

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

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

Михаил Бараблин

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

Вопрос 7. Как переход в облако меняет роль внутренней ИТ-службы и службы безопасности? Риски для ИТ-специалистов при миграции корпоративных инфраструктур в облако, есть ли они? Если да, то как им противостоять?

Владимир Ефремов

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

Вячеслав Медведев

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

Максим Захаренко

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

Марис Сперга

– Безопасность за последние два года трансформировалась из-за пандемии. Если раньше речь была о защите периметра, то теперь на смену пришла модель Zero trust. Также важно, чтобы все рабочие процессы поставщика услуг были сертифицированы, согласно стандартам безопасности. Например, стандарт ISO 27001 говорит о том, что предприятие понимает, как управлять безопасностью.

Миграция в облако с каждым годом становится всё проще, потому что появляются новые инструменты, особенно если мы говорим о решениях VMware. Нужно лишь спланировать заранее сам процесс миграции, подготовить план и следовать ему. В этот момент стоит просить поддержки провайдера, поскольку специалисты, работающие с облачными платформами (в том числе и Tet Cloud), уже имеют соответствующую компетенцию и опыт. А также могут подсказать, как уменьшить риски при миграции.

Александр Егоров

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

Чтобы противостоять рискам, надо постараться классифицировать до переезда все известные типовые риски (best practice). Определить меры и время предотвращения всех классифицированных рисков. Планировать тщательно каждый этап переезда, определять порядок и время на возврат сервисов в исходное состояние в случае проблем. Выделять окно на тестовый «переезд», пилотный и окончательный.

Евгений Черток

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

Риски есть – потеря данных, потеря работоспособности.

Евгений Макарьин

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

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

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

Дмитрий Ласьков

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

Руслан Косарим

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

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

Ольга Андреева

– Естественно, что происходит частичное делегирование прав и обязанностей. После миграции вычислений в облако у ИТ-специалистов нет необходимости обеспечивать работоспособность аппаратной части среды при всех сценариях, SaaS, PaaS и IaaS. Работоспособность обязуется обеспечивать провайдер. Но за соблюдением провайдером своих обязательств тоже кто-то из ИТ-специалистов должен наблюдать. Видимо, более пристального внимания потребует также качество каналов связи, их отказоустойчивость и дублирование. На самом деле в зоне ответственности специалистов после миграции оказываются две среды: локальная, в которой специалисты ответственны за всё, начиная с инженерных систем и заканчивая вычислительными устройствами, и удаленная, где специалисты управляют только программной частью, но не могут напрямую влиять на аппаратную. Мне кажется, что риски остаются очень похожими на те, которые ожидаются при размещении вычислительной среды в собственных ЦОД: сбой оборудования, потеря связи со стороны ЦОД, возможность вторжения вредоносных кодов. Только противодействие рискам теперь обеспечивают две команды специалистов – команда провайдера и ИТ-специалисты заказчика.

Евгений Филатов

– Внутренняя ИТ-служба претерпевает некоторые изменения, но они не столь кардинальны, нежели представляют себе отдельные специалисты, которые очень часто беспокоятся о том, что при переходе в облако они станут не нужны и будут уволены. Разработчики продолжат разрабатывать функционал, но уже с использованием большего набора инструментов, системные администраторы будут продолжать настраивать и поддерживать системный софт. Для ряда специалистов понадобится переквалификация, потому что вместо установки собственного оборудования (эти задачи снижаются вследствие переезда в облака) нужно, например, следить за оптимальными конфигурациями и моделями потребления облачных ресурсов, чтобы правильно их оптимизировать. Часть задач уходит, но появляются новые. Что касается ИБ – у них работа вообще не поменяется. Как уже отмечал ранее – она уже давно не ограничивается периметровой защитой.

Павел Коростелев

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

Что касается ИБ-службы, то переход в облако ведет к более жестким последствиям. Регулирование в облачной инфраструктуре иное, чем во внутренней ИТ-инфраструктуре. По сути, данные из внутренних сервисов уезжают куда-то непонятно куда. Придется менять подход к объектам данных – при внутренней инфраструктуре больше делали упор на инвентаризацию, определяя не забыли ли чего, а в случае с облаком придется в первую очередь следить за настройками ограничения доступа и безопасностью облачной среды. Дополнительно необходимо осваивать средства автоматизации, так как в облаках часто используются различные скрипты.

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

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

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

Джимшер Чалидзе

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

Артем Епишин

– При переходе в облако необходимо разделить зоны ответственности между собственной ИТ-службой и провайдером. Зачастую на модели IaaS провайдер отвечает за предоставление ресурсов в заказанном объеме, а все необходимые операции по защите данных (работа с антивирусами, средствами защиты информации, настройкой и обновлением операционных систем и т. д.) всё также продолжают лежать на плечах внутренней ИТ-службы.

Наталья Лещинец

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

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

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

Денис Безкоровайный

– Сотрудники ИТ- и ИБ-подразделений заказчика должны научиться быть специалистами по облачным вычислениям. Они должны четко понимать, как устроена облачная платформа используемого поставщика, как она работает, какие возможности предоставляет, а также знать потенциальные риски при использовании облачных вычислений, и как им противостоять. Современные образовательные учреждения и профессиональные ассоциации уже адаптировали и выпускают программы, направленные на новых пользователей облачных сред. Например, для аудиторов и сотрудников ИТ- и ИБ-подразделений уже доступны программы обучения и сертификации от Cloud Security Alliance, (ISC)² или The International Information System Security Certification Consortium, ISACA Ассоциация аудита и контроля информационных систем, программы обучения от поставщиков облачных платформ и другие образовательные возможности.

Иван Колегов

– Переход в облако не сильно меняет роль службы безопасности. С одной стороны, часть задач снимается, поскольку большинство крупных провайдеров предоставляет уже готовую облачную инфраструктуру, соответствующую 152-ФЗ. С другой стороны, появляются новые задачи. Например, если нет полного доверия к облачному провайдеру, то необходимо внедрить дополнительные меры безопасности и средства защиты – например, шифрование дисков и т. д.

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

Михаил Бараблин

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

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

Ключевые слова: виртуализация, облачные технологии, облачный провайдер, тариф, облачная инфраструктура, мультиоблако, SaaS, PaaS, IaaS

Подпишитесь на журнал
Купите в Интернет-магазине

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