Чёрные дыры облачных технологий

Вадим Заборский

В последнее время мы всё чаще и чаще сталкиваемся с термином «облачные технологии», особенно когда речь заходит об информационных системах, например, о CRM или ERP.

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

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

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

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

Вроде пока всё просто и понятно. 

Давайте ненадолго окунёмся в прошлое.

Автором «облачной технологии» (cloud technology)  или «облачных вычислений» (cloud computing)  является Джон Маккарти (John McCarthy), известный американский учёный, специалист по вычислительным машинам, автор понятия «искусственный интеллект». (Источник: Wikipedia). Макарти впервые ввёл в обиход термин «облачные вычисления» в конце 60х годов прошлого столетия. Сама идея позволяет использовать для сложных математических вычислений  компьютеры, соединённые в сеть и не занятые в данный момент другими задачами. Таким образом, для решения небольших задач в рамках проекта облачные вычисления позволяют уйти от необходимости иметь один дорогостоящий  супермощный компьютер, а вместо него использовать множество менее мощных «чужих» компьютеров, равномерно  распределяя между ними нагрузку с помощью специальной программы.

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

Насколько безопасна такая конфигурация «облака» с точки зрения сохранности помещаемых в неё коммерческих данных?

Вот тут-то и начинается самое интересное, поскольку чётко на этот вопрос мне не смог ответить ни один российский производитель программного обеспечения.
Дело в том, что компьютеры, обслуживающие «облако», в которое устанавливается информационная система,  физически находятся в Центрах Обработки Данных (ЦОД), по-другому их еще называют Дата-Центрами (от англ. Data Center).  Фактически от надежности Центра Обработки Данных и ваших договорных условий с ним зависит сохранность данных о клиентах вашей компании в «облаке».  Но при подписке на информационную систему, работающую в «облаке», вам не предоставляется возможность заключить договор с ЦОД.

Если у вас нет договора с ЦОД – нет официальных гарантий сохранности ваших данных в «облаке».  Иными словами, в случае внезапного прекращения доступа к клиентской базе из-за технического сбоя некому будет предъявить претензии. Задача усложняется, если Центр Обработки Данных, выбранный производителем информационной системы, находится за пределами России.

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

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

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

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

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

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

Самостоятельно вы можете выбрать только первые две организации. Выбор хостинг-провайдера, как правило, остаётся за производителем информационной системы. Повлиять на этот процесс практически невозможно, поскольку каждый производитель «облачной» информационной системы в течение определённого времени специально настраивает свою систему на работу с конкретным хостинг-провайдером (с учётом выбранного тарифа, операционной системы, выделяемых аппаратных ресурсов).
Ответы на вопрос о надежности хостинг-провайдера, характеристиках его оборудования и его известности сводятся обычно к словам «Ну, это же облачные технологии! Тут всё надёжно, и поэтому вам это знать не обязательно».

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

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

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

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

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

Иными словами, если кто-то из нескольких десятков или даже сотен сотрудников хостинг-провайдера или производителя «облачной» информационной системы проникнет в базу клиентов заказчика, скопирует личную информацию и воспользуется ей в своих интересах или в интересах третьих лиц, то, согласно закону №152-ФЗ, отвечать за это придётся заказчику информационной системы.

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

Что в итоге выбирать? Как обычно – решать вам.

Об авторе.
Вадим Заборский - директор компании ActiCom IT Consulting, член Экспертного Совета CRMONLINE.RU.