Организационно-правовые аспекты «облачного» аутсорсинга

Организационно-правовые аспекты «облачного» аутсорсинга

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

На Западе «облакам» доверяют. В Европе уже разработана и год назад представлена Европейская облачная стратегия. Предполагается, что распространение «облаков» внесет существенный вклад в экономику: эксперты прогнозируют рост ВВП в размере 250 млрд евро в год и 2,5 млн дополнительных рабочих мест. В США пошли еще дальше, намереваясь перенести часть государственных информационных систем в «облако».

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

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

Права и обязанности сторон

В современной практике операторы облачных услуг предлагают клиентам: SLA, в которых согласовываются различные аспекты предоставления услуги; NDA (Non-disclosure Agreement) – соглашение о конфиденциальности; договор-поручение оператора. «Работа с клиентскими данными в случае использования «облака» регламентируется, – поясняет Руслан Заединов, заместитель генерального директора, руководитель направления ЦОД и облачных вычислений компании «Крок». – Во-первых, существуют правовые ограничения, фиксируемые в договоре между провайдером и заказчиком. Они состоят в том, что провайдер гарантирует использование всех ресурсов, предоставленных ему заказчиком, исключительно для оказания услуг этому заказчику. Когда речь идет о сохранности данных, особенно конфиденциальных, такие оговорки, безусловно, необходимы».

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

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

Провайдеры, претендующие на качественный сервис, проводят соответствующие предварительные консультации заказчиков. «В SLA обязательно должен быть определен порядок и периодичность резервного копирования (бэкапирования), и, кроме того, обозначен уровень доступности услуги, проведено разграничение зон ответственности, – рассказывает Павел Моисеев, директор по качеству компании «Онланта». – Клиенту разъясняется содержание перечисленных выше пунктов, их значение для обеспечения сохранности информации. При необходимости разъясняются требования законодательства (подзаконных данных) РФ по информационной безопасности».

Тип услуги Ответственность провайдера (что он может контролировать и обеспечить со своей стороны) Ответственность клиента (что он может контролировать и обеспечить со своей стороны)
Iaas Контролируется и обеспечивается работоспособность и конфигурация инфраструктуры, предоставляющей сервис, то есть системы виртуализации и аппаратной среды Контроль работоспособности сервиса; Обеспечение эксплуатации сервиса; Операционная среда, прикладные системы, характер из взаимодействия и т.д.
PaaS Контролируется и обеспечивается работоспособность и конфигурация инфраструктуры, предоставляющей платформенный сервис: система виртуализации + операционная система + middleware (связность прикладных компонентов, балансировка нагрузки между ними) Контроль работоспособности платформенного сервиса; Обеспечение эксплуатации платформенного сервиса; Контроль за прикладной системой, реализующей бизнес-логику (хранит данные и обрабатывает их)
SaaS Контролируется и обеспечивается работоспособность и конфигурация инфраструктуры, предоставляющей программный сервис Обеспечение эксплуатации программного сервиса; Ответственность за добросовестность собственных сотрудников и защиту рабочих мест

Источники: «Крок», «Онланта», 2013



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

Непрерывность сервисов

Больше вопросов связано с бесперебойностью работы сервисов. Конечно, что каждый провайдер расскажет, какие меры предпринимаются для обеспечения непрерывности и катастрофоустойчивости. Однако объективными критериями могут служить резервирование «облака» в отдельно стоящем, удаленном дата-центре (а не в соседнем здании) и сертификация ЦОДа на соответствие уровню отказоустойчивости по системе Tier, лучше Tier III или Tier IV. При этом необходимо отметить, что в России обеспечение уровня и его сертификация – разные вещи. Многие провайдеры заявляют, что это слишком сложная и дорогостоящая для них процедура, что они организовали ЦОД, изначально заложив в инфраструктуру выполнение необходимых требований и потому сами приписывают себе определенный уровень отказоустойчивости. Возможно, они действительно выполнили необходимые требования, но без сертификации взаимоотношения из плоскости деловых переходят на доверительный уровень.

Уровни Краткое определение Время простоя (кол-во часов в год) Коэффициент отказоустойчивости
Tier I Базовая возможность, для технического обслуживания или ремонта требуется остановка оборудования. Могут быть перерывы в работе из-за сбоев во внешнем электропитании, в работе оператора передачи данных 28,8 99,671%
Tier II Выполнено резервирование критических узлов, но при техобслуживании необходимо отключение оборудования. Могут быть перерывы в работе из-за сбоев во внешнем электропитании, в работе оператора передачи данных 22 99,749%
Tier III Каждый компонент ЦОДа может быть отключен для техобслуживания и ремонтных работ без остановки ЦОДа. Могут быть перерывы в работе из-за сбоев в работе оборудования, в работе оператора передачи данных 1,6 99,982%
Tier IV Отказоустойчивый. Частный случай отказа оборудования или сбоя в работе оператора передачи данных не влияет на работоспособность ИТ-систем 0,4 99,995%

Источник: Uptime Institute, 2013



Чтобы уверить клиента в полной безопасности, провайдеры допускают аудит со стороны заказчика. Более того, такая проверка является обязательным пунктом любого NDA между клиентом и оператором. Хорошая практика – тестовые испытания по возможным сценариям сбоев. О том, как заказчик может удостовериться в должной компетенции провайдера, говорит Владимир Ковальский, генеральный директор компании «Медэск» (клиент «Онланты»): «В нашем случае архитектурное решение проектировалось совместно нашими специалистами и специалистами провайдера. В ходе работы с провайдером мы получили полное представление о самом поставщике, уровне его технологической оснащенности, профессионализме и всех нюансах работы с предлагаемым нам решением».

Уровень отказоустойчивости Организации, прошедшие сертификацию документов проекта Tier Certification of Design Documents Организации, прошедшие сертификацию работающей площадки Сoncurrently Maintainable
Tier III «Крок», «Сбербанк», DataSpace, «Ростелеком», IT-Park, «Мегафон» «Крок», «Сбербанк», DataSpace
Tier IV ЦОД Республики Мордовия

Источник: Uptime Institute, 2013



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

Кто ответит

На профильных конференциях, когда заходит речь о конфиденциальности и сохранности данных в «облаке», обязательно встает вопрос о разграничении ответственности между провайдером услуг и заказчиком. В зависимости от типа услуг (IaaS, PaaS, SaaS), провайдеры и заказчики по-разному разделяют между собой права и обязанности. Наиболее часто организационно-правовые проблемы у клиентов и операторов возникают при разграничении зон ответственности в области информационной безопасности.

Поставщик услуг обычно отвечает за безопасность основных компонентов облака: сетей, накопителей, серверов и виртуализации, рассказывает Михаил Марголин, генеральный директор компании Enspace, дочерней структуры Maykor. Предотвращение внутренних и внешних угроз внутри облачной инфраструктуры клиента – это обязанность непосредственно ИТ-специалистов компании-заказчика. Это значит, что в зону ответственности клиента входят: управление и обслуживание систем контроля доступа; управление политиками и правами доступа пользователей, включая парольную защиту; стандартное управление обновлениями ОС и приложений; ведение и анализ регистрационных журналов; мониторинг активности пользователей.

Мировой опыт показывает, что внутренние риски безопасности страшнее внешних. Первостепенным источником угроз для ИТ-систем компаний сейчас являются вовсе не хакеры или вредоносное ПО, а собственные сотрудники, констатирует Михаил Марголин. По данным аналитического центра компании InfoWatch, только за первое полугодие 2013 г. в мире выявлено 496 случаев утечки конфиденциальной информации. Эта цифра превышает прошлогоднюю на 18%. Скомпрометировано более 258 млн записей. При этом Россия вышла на второе место по количеству опубликованных утечек. В нашей стране цифра увеличилась на треть.

Утечки могут вызываться как непреднамеренными, ошибочными действиями, так и целенаправленным вредительством со стороны персонала. Например, продажа информации конкурентам, изъятие конфиденциальной информации или саботирование административных политик безопасности. Чаще всего происходит утечка персональных данных и платежной информации. По сведениям InfoWatch, количество таких утечек от общего числа составляет 93,8%, тогда как на долю коммерческой и государственной тайны приходится 3,4% и 2,6% угроз соответственно.

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

Законодательная ответственность

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

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

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

В России существует только один закон, касающийся персональных данных, но он достаточно четкий, в последние годы появились подзаконные акты, которые конкретизируют практику его применения. В частности, есть приказ ФСТЭК №21 – он достаточно подробно формулирует рамки и организационные требования, которым должна соответствовать информационная система провайдера, чтобы работать с тем или иным классом персональных данных. Так что законодательство проработано, осталось только выполнять его требования.

Как разделить ответственность: варианты

Какую-то часть ответственности в деле обеспечения сохранности персональных данных оператор может разделить с провайдером, подписав договор-поручение. «Если между оператором и провайдером (обработчиком) заключен договор-поручение, то оператор перекладывает часть ответственности по защите ПД на провайдера, – уточняет Павел Моисеев. – Если договора-поручения нет, то провайдер несет ответственность только за уровень услуг, предусмотренный SLA. Если не учитывать персональные данные, в отношении которых более или менее четко прописана юридическая ответственность, то в остальных случаях это предмет закрепленных договором взаимных договоренностей клиента и провайдера».

В компании «Медэск» уверены, что в случае ЧП с утечкой данных можно установить, по чьей вине это произошло, и отвечать будет не обязательно первоначальный оператор персональных данных. Рассказывает Владимир Ковальский: «"Медэск" является облачной медицинской платформой, предоставляющей участникам медицинского рынка решения по управлению бизнес-процессами. Большинство из этих бизнес-процессов построено на обработке и аналитике персональных данных пациентов, поэтому обеспечение информационной безопасности обрабатываемых данных – один из приоритетов нашей работы. Для обеспечения сохранности данных мы используем как собственные решения, так и возможности ИТ-аутсорсеров. Например, «Онланта» предоставляет нам виртуальные вычислительные мощности в облаке OnCloud.ru (серверы и системное ПО обеспечивают работоспособность выделенных ресурсов, защиту персональных данных в соответствии с SLA, Service Desk). В результате «Медэск» имеет возможность гибко управлять потребляемыми в OnCloud.ru ресурсами в соответствии с 152-ФЗ».

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

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

Разработка единых стандартов помогает сделать «облака» прозрачнее, Европейский рынок идет по этому пути. В России процветает индивидуальный подход, фактически сколько клиентов – столько типов договоров. «Мы вынуждены под каждого конкретного заказчика изобретать что-то новое», – сетует Руслан Заединов.

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

Наталья Николаева

Вернуться на главную страницу обзора