Одной из тенденций развития корпоративных ИТ является перекладывание сервисов, поддерживаемых внутренней ИТ-службой, на внешних подрядчиков. Что делает особенно актуальной задачу заключения устраивающего обе стороны договора поддержки и соглашения об уровне обслуживания (SLA).
Особенно явно эта тенденция проявляется при переходе к облачным вычислениям. На начальном этапе за всё связанное с компьютерами отвечала служба ИТ компании. В зону ее ответственности входила вся аппаратная часть — серверная или ЦОД, сети, серверы, системы хранения данных. Она же отвечала за поддержку операционных систем, систем виртуализации, баз данных, сред исполнения и приложений. При отсутствии ИБ-службы отдел ИТ отвечал и за вопросы информационной безопасности.
Причем чаще всего даже сейчас в компаниях нет никаких внутренних SLA. Все работы производятся на основании созданных регламентов и должностных инструкций, а оценка уровня поддержки, оказываемой бизнесу службами ИТ, осуществляется эмпирически.
Основные этапы перехода к облачным вычислениям
Первым этапом перехода компании к облачным вычислениям обычно бывает collocation. При этом компания ставит в ЦОД провайдера свое оборудование, а провайдер обеспечивает работу каналов связи с ЦОДом, решает вопросы энергопитания, вентиляции, пожарной безопасности, температурного режима помещений, физической безопасности оборудования заказчика, расположенного в ЦОДе.
Следовательно, в SLA должны быть прописаны требования по доступности ЦОДа через каналы связи, ответственность за скачки напряжения или отсутствие энергоснабжения, за соблюдение температурного режима. Если в ЦОДе размещаются видеокамеры для удаленного наблюдения службы безопасности клиента за своим оборудованием, то в SLA следует прописать, как долго эти камеры могут быть неработоспособными.
Следующий шаг — IaaS («инфраструктура как сервис»), когда покупателю не нужно приобретать свое оборудование. У провайдера он покупает не оборудование, а серверное время, пропускную способность каналов, дисковое пространство. Значит, к зоне ответственности провайдера добавляются серверы, системы хранения данных и системы виртуализации. И в SLA должны быть отражены показатели, которые характеризуют доступность серверов и данных.
Логичным продолжением делегирования прав на сопровождение ИТ-систем является PaaS («платформа как сервис»). Всё, кроме приложений, отдается на аутсорсинг провайдеру. Очень удобно для разработчиков ПО. Им не нужно думать не только об аппаратной части, но и об операционной системе, СУБД и вопросах информационной безопасности. У них есть нужная среда и инструменты разработки кода. Соответственно и в SLA должны найти отражение вопросы доступности платформы.
Заключительным этапом перехода к облачным вычислениям можно считать модель предоставления облачных сервисов SaaS («ПО как услуга»). На аутсорсинг отдается всё, включая прикладные программы. В обязанностях службы ИТ компании остается настройка уже готовых к эксплуатации программ.
Примером может служить электронная почта типа Mail.ru. Пользователя не интересует, где находятся серверы, какие операционные системы применяются, какие работают почтовые программы. Ввел свои данные и начал эксплуатацию.
Если сервис бесплатный, то и требовать что-то трудно. Но если сервис платный, например система интернет-банкинга, то логично подумать о SLA. Тогда, например, невозможность отправить платежи через Интернет из-за DDOS-атаки на серверы системы интернет-банкинга «Фактура» уже не будет только вашей проблемой.
На облачного провайдера перекладываются вопросы администрирования от системного ландшафта до прикладного ПО, установки патчей, обновления версий систем и программ и информационной безопасности на стороне провайдера.
Некоторые облачные провайдеры, например ActiveCloud, идут еще дальше и предлагают включить в зону своей ответственности канал до заказчика и его оборудование, работающее с каналом. Расширяя таким образом область действия своего SLA.
Но и в этом случае службы ИТ компаний без работы не останутся. Они будут заниматься разработкой стратегии ИТ, выбирать нужные ИТ-средства, осуществлять внедрение и поддержку систем, а также заключать SLA и контролировать их выполнение.
Оформление облачного SLA
Рассмотрим вопросы оформления облачного SLA. Независимо от используемой модели облачных вычислений при оформлении договора с провайдером облачных услуг проводятся следующие действия:
• заключается непосредственно сам договор между продавцом и заказчиком;
• формируется перечень предоставляемых услуг с указанием их стоимости;
• подписывается приложение к договору об оказании услуг — соглашение SLA.
В SLA входят:
• предмет соглашения;
• термины и определения;
• порядок и сроки оказания технической поддержки, показатели уровня доступности услуг;
• уровень технической поддержки и порядок расчётов;
• порядок подачи заявок;
• гарантии и компенсации;
• адреса и реквизиты сторон.
У наиболее «продвинутых», открытых для клиентов провайдеров облачных услуг на сайте публикуется типовой договор с типовым SLA. Это дает возможность провести предварительный анализ SLA. Хотя при заключении договора он все равно получится индивидуальным, зависящим от набора выбранных клиентом услуг.
Общими являются термины и определения. В этом разделе следует обратить внимание на то, чтобы в нём обязательно были наиболее важные определения.
Инцидент — любое событие, не являющееся частью стандартного (штатного) использования программ для ЭВМ, которое привело или могло привести к прерыванию или невозможности использования услуг заказчиком.
Время реакции — промежуток времени с момента получения заявки до получения письменного подтверждения приёма, квалификации заявки и начала работы над ней.
Обращаю внимание, что время реакции — это не время, за которое провайдер решит ваши проблемы. Это только максимально допустимое время начала этих работ. Всё это важно. Ведь любой подписываемый документ надо рассматривать так, как будто вы его уже подаете в суд. Так что четкие определения не помешают.
Также клиент выбирает уровень поддержки. Он может быть стандартным и повышенным (премиум). От этого, а также от категории и приоритета заявок заказчика зависят сроки их обработки. Например, если произойдёт инцидент (авария), то облачный провайдер ActiveCloud обязуется обеспечить срок обработки заявки менее чем 4 часа при стандартном уровне поддержки и за 1 час при поддержке уровня «премиум». В этом случае время реакции заявки на обслуживание снизится с 8 до 4 часов, заявки на предоставление информации — с 16 до 8 часов, заявки на изменение — с 24 до 16 часов.
Соответственно улучшится и показатель доступности. Если
Компенсации провайдера
Гарантия работы — это хорошо, но нужно прописать и компенсации за возможные нарушения SLA. Вот тут начинается самое интересное. Так, в SLA ActiveCloud записано, что «заказчику предоставляется компенсация путём вычета 5% из стоимости услуг в текущем отчётном периоде за каждые полные 30 минут недоступности услуг и/или превышения сроков оказания технической поддержки, но не более 100% в совокупности».
Аналогичная ситуация и с международными облачными провайдерами. В SLA Microsoft Azure прямо написано, что такие выплаты «ни при каких обстоятельствах не должны превышать ежемесячные взносы на обслуживание клиентов». Только само SLA более универсально и юридически проработано — об этом говорит хотя бы то, что его текст занимает 28 страниц.
Получается, что если сервис будет недоступен долго, в пределе — весь месяц, то все равно компенсация не превысит суммы месячной абонентной платы. Представляете, какими могут быть при этом штрафы за непоставку товара? А у банка просто отберут лицензию.
Конечно, это предельный случай, редко встречающийся на практике. Но он ясно показывает, что ИТ-службам заказчика не стоит бездумно перекладывать риски на облачного провайдера, а надо анализировать их самим.
Ключевые риски при использовании облаков
Рассмотрим ключевые облачные риски. За основу возьмем зарубежный источник — «Cloud Computing Benefits, risks and recommendations for information security, Rev B», ENISA. Основными рисками при использовании облачных вычислений являются следующие.
• Потеря управления — клиент уступает провайдеру контроль в облаке по ряду вопросов, которые могут влиять на безопасность. Если это ваша система — вы можете делать с ней всё и контролировать все процессы. Если отдали в облако — приходится во многом надеяться на квалификацию и надежность провайдера.
• Привязка к поставщику облачных услуг, сложность смены уже выбранного провайдера из-за отсутствия процедур и инструментов, которые могли бы гарантировать сохранность данных при переходе. Монополизм — это плохо. Кто даст гарантию, что провайдер в дальнейшем не поднимет цены, не снизит качество услуг или просто не развалится.
• Потеря изоляции среды при использовании общих ресурсов. Эта категория рисков охватывает отказ механизмов, отделяющих области хранения данных, оперативной памяти, маршрутизации. Злоумышленник может провести атаку guest-hopping, когда сначала атакуется менее защищенная виртуальная машина, размещенная на том же физическом оборудовании, что и интересующая его, а потом уже через нее идет уже непосредственная атака на нужный ресурс. В публичном облаке не исключено и прямое легальное размещение виртуальной машины злоумышленника, с которой идет атака на другие виртуальные машины.
• Риски соответствия, когда облачное решение может не соответствовать существующим стандартам или требованиям регуляторов. Например, требованиям по защите персональных данных.
• Компрометация интерфейсов управления, когда, используя уязвимости в браузерах, злоумышленник через удаленный интернет-доступ получает широкие возможности по управлению ресурсами компании.
• Защита данных. Сложность проверки провайдера на предмет выполнения требований по защите данных, в том числе и требований регуляторов.
• Неполное удаление данных поставщиком. Запрос на удаление может быть выполнен не в полном объеме, и где-то, например в резервных копиях, данные остаются, что может противоречить требованиям регуляторов в вопросах удаления персональных данных.
• Зловредный инсайдер. Облачные вычисления могут быть использованы внутренним злоумышленником для незаконного доступа и незаконной передачи информации третьим лицам.
• Разрывы в цепи доступности услуг, когда из-за падения каналов связи или DDOS-атаки теряется доступ к облачным ресурсам у клиента.
С учетом разразившейся «войны санкций» я отдельно добавил бы еще и политические риски. Облачный сервис легко заблокировать — примером могут быть санкции против Крыма.
Не все облака одинаково полезны
Большинство этих рисков существуют и для традиционных ИТ-систем. Меры по противодействию им хорошо известны и должны быть учтены при проектировании облака. Но только вот — учтены ли они на практике? И как на деле выполняются все необходимые регламенты по эксплуатации? Может ли провайдер выполнить обязательства, взятые на себя по SLA? Это зачастую трудно определить и специалисту.
Особенно сложно оценить риски в случае нестандартных решений. Возьмем для примера компанию Inoventica. В ее ЦОДе под Владимиром (его еще иногда называют «деревянным» ЦОДом, так как бетон здания снаружи обшит деревом) используется оригинальная система охлаждения. Разработчики отказались от систем кондиционирования и для охлаждения применяют воздушные потоки с озера — старицы реки Клязьмы. Это исключает риски, связанные с выходом кондиционеров из строя, и сильно удешевляет сервис, обеспечивая экономию на электричестве.
Но при этом возникают другие нестандартные риски, сезонные. Например, риск затопления в результате половодья. Можно верить разработчикам, утверждающим, что вода до уровня пола при половодье не доходит, но лучше бы иметь независимую экспертизу с анализом подъема уровня Клязьмы за длительный период времени, например за сто лет.
Не все облака одинаково надежны. Но в этом могут разобраться только профессионалы. Для того чтобы разобраться, нужны отраслевые стандарты и сертификация.
Сейчас сертификацию проходят некоторые ЦОДы. Наибольшую известность получили сертификаты Uptime Institute. Эта организация разработала систему Tier, определяющую уровень надежности и отказоустойчивости ЦОДов. Сертификаты выдаются на проект, на уже построенный ЦОД и на эксплуатацию. Несколько российских ЦОДов имеют сертификат Tier на построенный ЦОД. Информации об уже проведенных сертификациях на эксплуатацию в российских ЦОДах найти не удалось.
Сама процедура не дешевая и обойдется заказчику в сумму более 100 000 долл. Что, конечно, скажется и на уровне цен для клиента. Кроме того, в ней не учитываются российские требования по информационной безопасности. Так что вопрос создания своей системы сертификации, пусть даже на базе зарубежной локализации, давно назрел.
Все это справедливо и для используемых программных средств. Ведь облако — это прежде всего софт. А тут со стандартами и сертификациями совсем плохо. Возьмем вопрос защиты облака от DDoS-атак. Например, систему защиты от сетевых атак invGuard. Вроде выглядит неплохо — защищает от внешних и внутренних DDoS, выявляет бот-сети. Но как реально пользователь может ее проверить? Взять на тестирование и организовать на себя DDoS-атаку?
Остается надеяться на экспертные оценки, на статьи в прессе и доклады на конференциях. Впрочем, все это уже выходит за замки обсуждаемой темы облачных SLA.
SLA — это не страховка на все случаи жизни
Облачные вычисления последовательно завоевывают популярность у нас в стране. У них много преимуществ, за ними будущее. Но не надо думать, что все облачные проблемы можно решить с помощью SLA.
Да, облачные вычисления снижают риски. Да, аутсорсинг перекладывает часть рисков на провайдера. Да, SLA — это важно и надо внимательно относиться к его содержанию. Но в целом надо понимать, что SLA — это не волшебная палочка и всех ваших проблем с его помощью провайдер не решит.
Нужно не надеяться на обещаемое максимальное время недоступности сервисов, согласованное в тексте, а думать самим. Над репутацией провайдера и вопросом, насколько можно ему доверять. Над тем, какие риски можно передать провайдеру, а какими лучше заниматься самостоятельно. Самим оценивать риски и изучать схемы резервного копирования, репликации баз данных, катастрофоустойчивости системы.
Как известно, спасение утопающего — дело самого утопающего. Вас может не интересовать репутация доктора, если, конечно, не интересует итоговый результат вашего лечения.
SLA — не страховка на все случаи жизни. Но всё же это рычаг, с помощью которого вы можете воздействовать на провайдера. Вполне легальный и юридически правильно оформленный. И недооценивать его важность нельзя.
Автор статьи — канд. техн. наук, член ассоциации RCCPA.
