Призрак «облака». Чего и почему боятся заказчики?

Компании теряют контроль над своими данными и (или) сервисами, которые они передают в «облако». Какие риски возникают у компании-заказчика, использующей ресурсы публичного «облака»? Как их минимизировать? Согласно исследованиям аналитического агентства Coleman & Parker (июнь 2011 года), более 70% CIO в России намерены использовать «облачные» технологии для обеспечения нужд граждан, заказчиков и сотрудников своих организаций, а около 50% собираются в 2012 году предоставлять более 40% ИТ-услуг через публичное или частное «облако». Но эти благие намерения существуют отдельно от реальности.

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

Чтобы тайное не стало явным

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

Технический консультант компании Symantec Олег Просветов рекомендует внимательно читать условия предоставления услуги и составить четкое представление о том, в какой стране будут обрабатываться данные. Законодательство США, например, оставляет больше возможностей для доступа провайдера «облачных» услуг к данным клиентов. В Германии, Франции или Швейцарии этот риск гораздо ниже. Если «облачный» хостинг расположен в России, Александр Додохов, руководитель проекта компании «Аладдин Р.Д.», предлагает не сбрасывать со счетов коррупцию, а также специфические для РФ методы ведения бизнеса и конкурентной борьбы. Поэтому стоит задать провайдеру вопрос о возможности выбора дата-центра, в котором будут размещены данные клиента.

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

Для оценки рисков компрометации данных Денис Безкоровайный, технический консультант Trend Micro, организатор российского отделения Cloud Security Alliance, CISA, CISSP, CCSK, советует составить как можно более полное представление о жизненном цикле данных клиента у провайдера. Как происходит уничтожение данных одного заказчика перед предоставлением освободившихся ресурсов другому? Как происходит уничтожение физических носителей с данными? Проводится ли обработка клиентских данных в тестовой среде провайдера — и если да, то защищена ли тестовая среда (и доступ к ней) так же, как производственная? Проводится ли предварительная проверка персонала провайдера и специалистов подрядных организаций, имеющих доступ к данным заказчика? Эти вопросы обязательно надо задавать провайдеру, добиваться внятного ответа.

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

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

— Чтобы снизить риски конфиденциальности данных, кроме мер, принимаемых самим клиентом, требуется наличие детективных и превентивных мер на стороне провайдера, — настаивает Денис Безкоровайный. — Необходимо обязательное логгирование доступа сотрудников провайдера к данным клиентов, минимизация прав доступа по принципу необходимости для выполнения служебных обязанностей и прочие стандартные меры разграничения и контроля доступа. Заказчикам необходимо знать, как «облачный» провайдер выполняет эти меры и смогут ли сотрудники заказчика получить доступ, например, к журналам регистрации событий в системах провайдера в случае инцидентов.

Безопасный переход в «облако» невозможен без формализации ИТ-процессов заказчика. «Необходима определенная зрелость компании в части соблюдения стандартов работы с конфиденциальными данными, — предупреждает Руслан Заединов. — Если система, в защите которой есть бреши, будет перенесена в „облако», проблемы не исчезнут. Например, возможна ситуация, когда администратор заказчика по ошибке или по неосторожности дает доступ через Интернет к системе, расположенной в „облаке», а пароль на вход оставит „простым». В этом случае взломщик может с одной–двух итераций подобрать пароль и проникнуть в прикладные системы заказчика, несмотря на все меры по защите, которые предпринял провайдер. Ведь „облако» посчитает взлом обычным входом пользователя, имеющего пароль».

Проблемы на большой дороге

«Облачные» сервисы подразумевают наличие постоянного интернет-соединения. Поэтому возникают риски, связанные с каналами передачи данных: утечка информации (перехват во время передачи) и отказ каналов. Здесь компания-заказчик может выиграть от перехода в „облачную» среду. «Во-первых, — рассказывает Николай Агринский (Softline), — провайдер „облака» более критически относится к выбору провайдера передачи данных и имеет резервные каналы (скорее всего, не один). Во-вторых, в случае если компания имеет территориально распределенную структуру или предоставляет какие-либо сервисы для своих клиентов (контрагентов), выход из строя каналов связи в головном ЦОД не повлияет на работоспособность остальных подразделений, так как „облако» со всеми сервисами и информацией будет доступно».

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

«Облака» в законе

Рано или поздно компании, использующие публичные «облака», столкнутся со сложностями юридического характера. «Если в качестве сервис-провайдера выступает западная компания, то она, безусловно, будет подчиняться законодательству своей страны, в том числе и в области сотрудничества с силовыми структурами. Это следует учитывать, — подчеркивает начальник отдела информационной безопасности компании „Открытые Технологии» Алексей Филатенков. — Принятия особых мер требует также трансграничная передача персональных данных, которая может возникнуть в случае использования „облака»; здесь необходимо учесть требование российского законодательства».

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

Быть или не быть?

Закон Мёрфи гласит: «Если есть вероятность того, что какая-нибудь неприятность может случиться, то она обязательно произойдет». Ни один существующий риск нельзя исключить полностью. Но снизить до приемлемого уровня — можно.

— Для максимального охвата вопросов, которые надлежит рассмотреть при переходе в «облако», стоит максимально использовать мировой опыт и передовые практики в этой области, — считает Денис Безкоровайный. — Рекомендации для клиентов, рассматривающих возможность использования «облачных» вычислений с точки зрения информационной безопасности, можно найти на сайтах специализированных организаций, таких как Cloud Security Alliance (некоторые документы переведены на русский язык российским отделением Cloud Security Alliance Russian Chapter1) или ENISA (European Network and Information Security Agency)2.

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

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

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

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

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

С передачей сервиса в «облако» управление информационной безопасностью не прекращается. Независимо от модели предоставления «облака» именно потребитель сервиса осуществляет управление информацией, в том числе доступом к ней, несет ответственность за ее достоверность и полноту. В данном случае базовыми мерами, как и для традиционной модели предоставления сервисов, могут являться принцип «наименьших привилегий» («least privileges») и «разграничения обязанностей» («segregation of duties»). Необходимо обеспечивать защиту информации при передаче ее по каналам связи при помощи криптографических средств; рекомендуется также в целях исключения доступа к данным в «облаке» третьими лицами осуществлять их шифрование. Желательно отслеживать, какие данные перемещаются в «облако», не допускать перемещения строго конфиденциальной информации, операций по перемещению данных, противоречащих требованиям отраслевых стандартов или государства (например, требований по трансграничной передаче персональных данных).

В последнее время активно ведется разработка новых стандартов и сводов рекомендаций, касающихся обеспечения информационной безопасности в рамках «облачных» моделей предоставления сервисов. Николай Агринский приводит перечень таких документов. К ним можно отнести публикации международной некоммерческой организации Cloud Security Alliance — например, Security Guidance for Critical Areas of Focus in Cloud Computing: это свод «лучших практик» по обеспечению безопасности при «облачных» вычислениях. Активно ведется разработка новых стандартов ISO 27017 (Security in cloud computing), ISO 27018 (Privacy in cloud computing), ISO 27036-5 (Information security for supplier relationships — Cloud Computing). Первый стандарт (ISO 27017) представляет собой дополнения и уточнения к ISO 27002 Code of Practice for Information Security Management (предшественником которого является стандарт ISO 17999 и на основе которого принят ГОСТ Р ИСО/МЭК 17799-2005 «Практические правила управления информационной безопасностью»); второй (ISO 27018) является дополнением к ISO 27017 и рассматривает аспекты обеспечения конфиденциальности и персональных данных в «облаках»; третий (ISO 27036) представляет собой руководство по оценке и снижению рисков, связанных с потреблением сервисов, которые предоставляют сторонние организации (в текущей редакции пятая часть стандарта рассматривает отношения с поставщиками при «облачной» модели предоставления сервисов).

Доверяй, но проверяй

При принятии решения о переносе ИТ-сервисов в «облако» нужно весьма ответственно подойти к выбору сервис-провайдера.

— Прежде всего следует определиться с тем, какие информационные активы предполагается поместить в «облако», определить, какой у них уровень критичности, — говорит Иван Ермаков, руководитель отдела поддержки приоритетных заказчиков компании НР в России. — Для хранения и обработки информации низкой критичности можно руководствоваться при выборе провайдера принципом оптимизации соотношения «цена — качество». Для критичных систем следует обстоятельно взвесить все риски, изучить и при необходимости модифицировать договор с провайдером (SLA), предусмотреть механизмы контроля и отчетности. Кроме того, нужно получить от провайдера объективные подтверждения возможности выполнять обязательства, которые оговариваются в SLA. Наконец, необходимо оценить накладные расходы на выполнение перечисленных действий.

В SLA следует предусмотреть ответственность провайдера за возможные инциденты ИБ, не связанные с деятельностью клиента. К таким инцидентам могут относиться потеря доступности из-за отказов оборудования или каналов связи ЦОД, полная потеря данных по причине пожаров, потеря конфиденциальности в случае инсайдерских атак и т. д. Штрафные санкции могут быть хорошим драйвером для «облачного» провайдера в части внедрения дополнительного контроля инфраструктуры и процессов. При этом всегда стоит помнить, что SLA не является стопроцентной гарантией выполнения закрепленных в нем обязательств. Поэтому необходимо заранее оценивать уровень ущерба от его возможного невыполнения.

Провайдер должен обладать хорошей репутацией и устойчивым финансовым положением. Это служит определенной гарантией его заинтересованности в предоставлении качественных и надежных услуг. При реализации риска такой провайдер сможет компенсировать возникший у заказчика экономический ущерб. «Серьезные компании, предоставляющие услуги „облачных» технологий, в течение долгого периода времени вкладывают средства в обеспечение безопасности хранения и обработки данных в „облаке», — утверждает генеральный директор ONLYS Group Александр Никаноров. — Ведь это их работа, то, на чем они зарабатывают деньги. Любая нештатная ситуация отразится прежде всего на их репутации и в дальнейшем — на бизнесе. Такие компании не будут экономить на том, что обеспечивает им прибыль».

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

Если организация-провайдер сертифицировала свои процессы по стандарту ISO/IEC 27001, то такой сертификат также может являться хорошим подтверждением выполнения провайдером комплекса мер по защите информации. «Конечно, при условии что сертифицирован действительно важный основной процесс, а не вспомогательный для основной деятельности — например, оказание технической поддержки клиентам», — уточняет Денис Безкоровайный. Сертификация и независимый аудит — это длительные и дорогостоящие процедуры, поэтому неудивительно, что не многие провайдеры «облачных» сервисов (тем более в России) готовы идти на такие затраты.

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

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

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

Перечень основных рисков

Николай Агринский, руководитель экспертной группы направления информационной безопасности компании Softline, приводит перечень основных рисков, которым подвержена пользовательская информация в «облачных» сервисах:

• Отказ в обслуживании вследствие недоступности подключения к «облаку» (проблемы с каналами связи).
• Получение злоумышленниками доступа к пользовательской части сервиса в результате обхода системы аутентификации и контроля доступа к «облаку», использования уязвимости в API управления сервисом.
• Кража пользовательской информации сотрудниками провайдера — например, в результате физического доступа к оборудованию или использования административных привилегий в системах управления сервисом.
• Риск получения доступа к пользовательской информации другими клиентами провайдера в результате сбоя или успешной атаки на программную среду, отвечающую за разделение обработки и хранения данных.
• Повреждение или безвозвратная потеря данных в результате сбоев оборудования либо ошибок сотрудников провайдера «облачных» вычислений.
• Утечка информации в результате несоблюдения провайдером правил информационной безопасности при утилизации носителей данных.
• Кража информации третьими лицами, оказывающими разнообразные услуги провайдеру «облачных» вычислений.