Ситуации, с которыми не может справиться облачная электронная почта

Аналитики Gartner перечисляют 10 ситуаций, в которых облачная электронная почта не справится с возложенной на нее задачей.

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

Безопасность. Обсуждение безопасности электронной почты без должного углубления в вопрос приводит, порой, к совершенно противоположным результатам.
К примеру, административный контроль – это часть системы безопасности, определяющая кто и какие права имеет на редактирование свойств системы электронной почты. Четко прописанные административные права могут повысить безопасность системы, разрешая только нескольким доверенным лицам управлять критически-важными атрибутами. Поставщики облачных решений в общем случае не предлагают таких инструментов, создавая тем самым дополнительные риски.
Другой пример – поддержка Transport Layer Security (TLS), метода шифрования, обычно используемого компаниями для безопасных коммуникаций с партнерами. Поставщики облачных решений поддерживают «авантюрный» TLS (когда TLS используется только если его поддерживает и получатель, и отправитель), но неспособны ввести «обязательный» TLS (когда сессия TLS является неотъемлимый условием передачи сообщения).

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

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

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

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

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

Непрерывная работа (uptime). Электронная почта получает запоздалое признание в роли инструмента для решения ответственных бизнес-задач; одновременно организации становятся более требовательными к такому параметру, как время непрерывной работы (uptime) своих систем. Уже сейчас можно найти множество компаний, переходящих от лицензионного соглашения, предусматривающего uptime 99.5%, к лицензионному соглашению с uptime 99.9%. Обычно затраты на этот переход выражаются во вложениях в аппаратную избыточность и усовершенствование процессов. Избыточность порождает дополнительную сложность; кроме того, урезаются временные окна, отведенные на обслуживание системы.

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

Время восстановления (recovery time objective, RTO) и точка возврата (recovery point objective, RPO). Учитывая, что система электронной почты постепенно признается критично-необходимым бизнесу сервисом, на первый план выходят требования к подсистемам восстановления после сбоев, согласно которым восстановление данных должно занимать менее 4 часов, а точка возврата (время, прошедшее с последнего сохранения) находиться менее чем в 5 минутах. Инвестиции в реализацию этих требований могут быть огромны и, естественно, увеличивают сложность системы электронной почты. Соответствие самым жестким условиям может привести к реальному конкурентному преимуществу, когда после критического сбоя организация сможет достаточно быстро получить работоспособную электронную почту, в то время как конкуренты будут простаивать. Что касается поставщиков облачных решений, то они могут предлагать решение с характеристиками, не соответствующими внутренним критериям компании. К примеру, у основных поставщиков облачной электронной почты точка возврата варьируется в диапазоне от 10 минут до 24 часов.

Мобильность. Имея на то свои бизнес-причины, пользователи могут требовать доступа к электронной почте с различных мобильных устройств и из удаленных географических точек. Несколько лет назад подобная услуга была ориентирована на элиту: совсем не многие поддерживали работу с мобильными клиентами, причем, в основном подобные решения реализовывались на базе BlackBerry Enterprise Server (BES). Но теперь большинство работников интеллектуального труда требует доступа к почте как через браузер, так и из мобильных клиентов на самых разных платформах. Более глубокая поддержка мобильных устройств и веб увеличивает сложность и стоимость системы, особенно в организациях, озабоченных вопросами безопасности. И облачные сервисы здесь не будут решением. Большинство облачных систем электронной почты поддерживает ActiveSync, доступ через браузер и службы BES. Однако стоимость этих опций достаточно высока, и поставщики решений могут быть не в состоянии обеспечить требуемый уровень безопасности и контроля мобильного доступа.

Хранилище. Почтовое хранилище, вероятно, главный источник беспокойства пользователей электронной почты. Средний объем хранилища, расположенного на сервере, варьируется от 300 до 500 Мб в расчете на один почтовый ящик. Это заставляет пользователей тщательно следить за сохраняемыми сообщениями. Более крупные хранилища могут создаваться на сервере при помощи технологий, вроде групп доступности баз данных в Exchange 2010. Но этот подход может добавить сложности системе, ведь он требует наличия до четырех копий почтового хранилища на разных жестких дисках.

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

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

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

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

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