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

В целом, большинство ИТ-директоров уже знают что-то о преимуществах и недостатках облачных сервисов. Вспомните провайдеров приложений (ASP) из 2000-го. Даже тогда цены, гибкость и перспектива экономии на ИТ-инфраструктуре говорили в пользу ASP-решений. В наш лексикон входили соглашения об уровне обслуживания (Service Level Agreement, SLA), зарождалась информационная безопасность. Большой проблемой была передача контроля поставщику (особенно для критичных приложений), ее корни растут из середины 80-х, со времен появления аутсорсинга.

Вернемся в 2012-й, в мир, где есть:

  • публичные облака (публично доступная инфраструктура);
  • частные облака (инфраструктуры, функционирующие для частных клиентов);
  • гибридные облака (комбинация публичных и частных облаков);
  • различные сервисные модели облачных сервисов — ПО как сервис (Software as a Service, SaaS), платформа как сервис (Platform as a Service, PaaS) и инфраструктура как сервис (Infrastructure as a Service, IaaS).

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

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

Предложенный мною подход состоит из трех частей.

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

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

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

В действительности акцент на приватности данных, информационной безопасности и соответствии законодательным нормам — то, что более всего отличает процесс оценки облачных сервисов в 2012 г. от оценки ASP-решений в 2000-м.

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

Соглашения об облачном сервисе: обсуждение лучших практик

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

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

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

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

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

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

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

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