Стандарты для облаков: зачем и какие?

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

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

Четкое определение облака

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

Облачная модель очень похожа на несколько предыдущих поколений сервисных моделей: разделение машинного времени 60-70-х годов, клиент-серверные архитектуры 80-90-х и поставка приложений в виде сервисов недавних лет. Но если доставка сервисов существует уже полвека, какие же изменения вызвали такой ажиотаж?

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

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

Стандарты для облака

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

Потребность в сервисах обмена пакетами данных, пересылки электронной почты и распределенного доступа к информации с гиперссылками логично привела к возникновению стандартов TCP/IP, SMTP и HTTP, однако переход на облака — это смена модели доставки сервисов, а не архитектуры фундаментальных протоколов. Для облачной электронной почты по-прежнему используется SMTP, для контакта с облачными ресурсами — DNS и т. д. Большинство аспектов вычислительной инфраструктуры для облаков не требуют изменений, но почему же тогда так громко звучат требования разработки стандартов для облаков? Ответ краток — пользователи нервничают. Организации, рассматривающие идею перехода в облако, опасаются попасть в зависимость от неверно выбранной технологии или поставщика. Из истории развития Интернета известно, что только стандарты могут защитить пользователей от попадания в «заложники» к поставщикам, которые, в свою очередь, хорошо понимают это беспокойство и стремятся смягчить опасения заказчиков, разыгрывая карту стандартов. Потенциальным заказчикам сообщается: стандарты будут гарантировать, что те не пожалеют о переходе на облачные вычисления, даже если им не понравится сам поставщик.

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

Фундаментальная путаница

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

Назовем первый тип предписывающими стандартами — спецификации, которые широко обсуждаются в научных и академических кругах. Эти стандарты определяют «кровавые подробности» формата, протокола или интерфейса, описывая, как заставить системы интероперабельно взаимодействовать друг с другом. Эти стандарты обязаны быть полными и исчерпывающими — любое излишество или упущение считается дефектом. Примеры предписывающих стандартов: SMTP и TCP/IP, MIME и Open Document Format, а также интерфейсы вроде USB или Firewire (IEEE 1394). Почти все стандарты, обсуждаемые в этой статье, относятся к этому типу.

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

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

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

Предписывающие облачные стандарты

Сама по себе модель облаков не вводит никаких новых функций или приложений. Облачная электронная почта, например, по-прежнему передается по SMTP в формате MIME, и чаще всего доступ к ней происходит по протоколу POP или IMAP. Никаким из этих стандартов не требуются изменения при переносе в облако. Конечно, стандарты непрерывно развиваются, и переход в облако может предъявить какие-то новые требования к уже существующим стандартам, особенно к наименее развитым, однако в таких случаях чаще всего понадобится не больше чем расширение уже имеющейся спецификации.

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

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

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

Смена облачного провайдера в чем-то похожа на смену поставщика приложений, однако сама роль первого создает дополнительный уровень сложности. Представим, например, что компания, еще не пользующаяся облаком, решила перенести свою электронную почту с Microsoft Exchange на Lotus Notes/Domino. Такая миграция потребует внедрения нового клиентского ПО, переоснащения серверов, переобучения пользователей и переноса данных приложений (в нашем случае почтовых баз).

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

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

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

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

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

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

Оценочные облачные стандарты

Если предписывающие стандарты диктуют конкретные инструкции по выполнению некоторого процесса, то оценочные описывают общепринятые методы оценки качества выполнения процесса. Вместо того чтобы давать новые функциональные возможности, такие стандарты позволяют оценивать качество предлагаемой функциональности. Эпитет «оценочный» в названии стандарта не означает, что он менее важен; на самом деле соответствие таким стандартам, как, например, Payment Card Interface Data Security Standard (PCI-DSS) или Federal Information Processing Standard (FIPS) 140-2, часто является обязательным.

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

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

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

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

Управление электронной почтой в облаке

Электронная почта считается стабильным, хорошо задокументированным приложением, хотя это не совсем так; однако, учитывая, что электронная почта применяется многие десятилетия, она является подходящим примером, на котором можно проиллюстрировать изменения (или отсутствие изменений) потребностей в стандартах при переносе в облако. Перенос электронной почты в облако не влечет за собой каких-то серьезных изменений соответствующих предписывающих стандартов: SMTP, MIME, IMAP, POP и DNS. Такой перенос также не влияет на эволюцию этих стандартов; например, спецификация DomainKeys Identified Mail (DKIM), регламентирующая электронные подписи для сообщений с привязкой к доменным именам, была разработана не для облаков, но она к ним вполне применима. Как уже говорилось, если анализировать возможные области, в которых могли бы понадобиться новые предписывающие стандарты, то результаты такого анализа будут одинаковыми и для облачной, и для необлачной модели.

Другое дело оценочные стандарты, например безопасность: в «дооблачном» мире поставщики продавали (или авторы проектов категории Open Source выпускали) почтовые серверы —Exchange, Domino, sendmail, postfix и т. д. Каждый из них время от времени требует установки заплат безопасности, однако общеизвестно, что главная ответственность за обеспечение безопасности лежит на операторах самого почтового сервиса. Иными словами, даже самый безопасный код в мире не спасет от халатности операторов. Таким образом, защищенность, обеспечиваемая поставщиком, редко является решающим фактором для заказчика, когда он выбирает программный продукт для покупки.

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

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

***

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

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

Натаниэл Боренстейн, Джеймс Блейк ({nsb , jblake}@mimecast.com) — сотрудники компании Mimecast.