Журнал о системах электронного документооборота (СЭД)
Информационная безопаснось в ECM

Информационная безопасность облаков. Миф или реальность?

  7 комментариев Добавить в закладки

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

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

Миф первый: ИТ-безопасность внутри компании обеспечена более надежно, чем в облаке

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

Перечислим основные преимущества облачных провайдеров перед корпоративной ИТ-инфраструктурой:

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

Ответственность провайдера перед компанией-клиентом регулируются соглашением об уровне обслуживания (Service Level Agreement, SLA), а также соглашением о не разглашении (Non-Disclosure Agreement, NDA), которое определяет как и какой доступ к данным клиента провайдер может получить в зависимости от ситуации, как регистрируется факт получения доступа к данным, какие штрафные санкции применяются в случае нарушений.

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

Миф второй: данные из облака похитить проще, чем изнутри компании

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

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

Основные риски облачных сервисов и рекомендации по их снижению

 

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

Опишем основные риски информационной безопасности, которые наиболее часто появляются при работе с облаком:

Нарушение законодательства со стороны других пользователей облака с последующим изъятием оборудования.

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

Рекомендации: инфраструктура провайдера должна позволять переносить мощности клиента на резервное оборудование в случае недоступности основного.

Передача данных по Интернет-каналу.

Обмен данными с облаком осуществляется непосредственно через Интернет-канал, соответственно, без надлежащей защиты злоумышленники теоретически могут получить передаваемые данные (тела документов, пароли, персональные данные и т.д.).

Рекомендации: необходимо использовать те облачные сервисы, которые обеспечивают своим пользователям защиту передаваемых данных (VPN-соединение, HTTPS и прочие защищенные протоколы передачи).

Ограниченные ресурсы.

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

Рекомендации: уточните у провайдера, каким объемом ресурсов он фактически располагает. Запросите экскурсию в ЦОД провайдера, если есть такая возможность. Проводите регулярное нагрузочное тестирование предоставляемых сервисов (IaaS и PaaS).

Экономические последствия DDoS-атак.

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

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

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

Прочие риски, о которых часто забывают

 

Безопасность данных в облаке – это не единственный риск.

●    Пользователи облаков могут потерять собственные компетенций в области поддержки инфраструктуры и/или могут попасть в зависимость от внешнего поставщика услуг.

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

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

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

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

 

Источник: TAdviser

Ещё материалы автора
Похожие записи
Комментарии (7)
Максим Кайнер 27 ноября 2015 г. 14:48  

Отличная статья, Андрей!

Но берегись — журналисты любят задавать нам вопросы про безопасность, теперь будем их к тебе отсылать, как к эксперту.

Михаил Романов 28 ноября 2015 г. 14:49  

Хотелось бы уточнить ряд моментов:

1. Фраза

Облака как модель организации ИТ

Что вы имеет в виду под термином "модель организации ИТ"? 

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

2. Также я не понял как соотнести два ваших утверждения:

к самим приложениям и данным пользователя провайдер доступа обычно не имеет

и

на уровне приложений пользователь самостоятельно должен обеспечить безопасность данных

Вы всё же уточните - провайдер не имеет доступ к данным или всё же пользователь должен данные защищать. А если не имеет, то каким техническим образом это реализуется (конечно хочется увидеть конкретные реализации у конкртеных поставщиков, а не теоретически возможные варианты).

3. По поводу NDA

также соглашением о не разглашении (Non-Disclosure Agreement, NDA), которое определяет как и какой доступ к данным клиента провайдер может получить в зависимости от ситуации

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

4. По поводу похищения данных (втором мифе)

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

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

Если же вы намекаете централизацию ИТ-сервисов как таковую, то всё равно не понятно - какая разница: разворачиваете вы системы в облаке или в собственном data center?

5. По поводу переноса на резервную площадку:

Рекомендации: инфраструктура провайдера должна позволять переносить мощности клиента на резервное оборудование в случае недоступности основного

Как именно должна соблюдаться ваша рекомендация?

Если вы имеете в виду, что провайдер должен позволять вам бесплатно занять другие сервера взамен утраченных, то это естественная процедура и есть практически у всех (исключая самых упоротых и "бюджетных"). Но это, простите, ничем не лучше, чем иметь резервные средства для переключения на "запасного" поставщика - вы всё равно будете развертывать свои системы заново (выигрышь будет равзе что в случае, когда "изъятие" коснулось лишь части ваших систем.

И да, сразу спрошу - а как вы предлагаете тестировать данную возможность (дабы убедиться, что у провайдера она реально есть, а не просто декларируется)?

6. Про передачу по интернет-каналу

Рекомендации: необходимо использовать те облачные сервисы, которые обеспечивают своим пользователям защиту передаваемых данных (VPN-соединение, HTTPS и прочие защищенные протоколы передачи).

Скажите, а вы много видели поставщиков, которые не предоставляют что-то из перечисленного (остобенно в случае IaaS - где вам дается, по сути, "чистая" машина, на которой вы вольны устанавливать всё, что вам заблагороссудится)?

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

7. Про ограничения ресурсов провайдера
 
Рекомендации: уточните у провайдера, каким объемом ресурсов он фактически располагает. Запросите экскурсию в ЦОД провайдера, если есть такая возможность.

Во-первых, не очень понятно, что вам даст осмотр ЦОДа в плане оценки ресурсов. Вы будете считать количество стоек и проверять соответствие их характеристик заявленным? Или что?

А во-вторых, значение имеют не номинально имеющиеся ресурсы, а процент их фактической загрузки (в смысле, какая вам разница будет у провайдера 1 на 100% загруженный сервер или 1000), а это вам может сказать только сам провайдер. И прогноз по её росту, а это вам вообще врятли кто-то скажет.

 

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

Вадим Майшев 30 ноября 2015 г. 18:17  
необходимо использовать те облачные сервисы, которые обеспечивают своим пользователям защиту передаваемых данных (VPN-соединение, HTTPS и прочие защищенные протоколы передачи).

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

Защищенным облаком может быть только облако, в котором все хранится только в зашифрованном виде.

 

Андрей Ардашев 02 декабря 2015 г. 13:05  
Вадим Майшев 30 ноября 2015 18:17
Криптографические протоколы предназначены для защиты канала. Но есть нюанс - криптосредства и криптоключи должны размещаться строго в контролируемой зоне. Защищенным облаком может быть только облако, в котором все хранится только в зашифрованном виде.

 Вадим, благодарю за дополнение. Все верно, данные в защищенном облаке должны шифроваться.

 

 

Андрей Ардашев 02 декабря 2015 г. 14:28  

Михаил, приветствую! постараюсь ответить по всем Вашим вопросам.

Михаил Романов 28 ноября 2015 14:49

1. Фраза Облака как модель организации ИТ Что вы имеет в виду под термином "модель организации ИТ"?  Под моделью организации я всегда понимал способ внутреннего устройства ИТ-подразделения (выделение отделов их связи и соподчиненность) и их взаимоотношения с остальными структурами организации (последнее время популярна сервисная модель). Но как она может зависеть от способа хостинга ("облака") я не понимаю. Проясните пожалуйста.

Под термином "модель организации ИТ" в данном случае понимаю способ организации ИТ в той или иной организации с учетом используемых технологий (в том числе облако) и, конечно же, регламентов.

Михаил Романов 28 ноября 2015 14:49

2. Также я не понял как соотнести два ваших утверждения: к самим приложениям и данным пользователя провайдер доступа обычно не имеет и на уровне приложений пользователь самостоятельно должен обеспечить безопасность данных Вы всё же уточните - провайдер не имеет доступ к данным или всё же пользователь должен данные защищать. А если не имеет, то каким техническим образом это реализуется (конечно хочется увидеть конкретные реализации у конкртеных поставщиков, а не теоретически возможные варианты).

Все просто.
1. провайдер не должен иметь доступ к данным пользователя. Исключением является какой-либо инцидент или запрос на обслуживание, в рамках которого требуется какая-либо модификация данных пользователя - это действие выполняется только с согласия пользователя.
2. В случае IaaS и PaaS провайдер обеспечивает безопасность на уровне гипервизора или платформы и может иметь доступа к данным пользователя вообще. Т.к. это зона ответственности пользователя. Например веб-сервис развернутый на ВМ, работоспособность которой обеспечивает гипервизор провайдера. Безопасность такого веб-сервиса должен обеспечивать именно пользователь, но не провайдер.
3. В случае SaaS провайдер фактически хранит данные пользователя и поэтому обязан обеспечить безопасность этих данных.
 
Михаил Романов 28 ноября 2015 14:49

3. По поводу NDA также соглашением о не разглашении (Non-Disclosure Agreement, NDA), которое определяет как и какой доступ к данным клиента провайдер может получить в зависимости от ситуации я первый раз слышу такую формулировку. NDA, как следует из его названия, это договор о непредоставлении информации третьему лицу, но никак не о том, какой доступ каждая из договаривающихся сторон имеет право получить.

 

Такой документ есть. Подробнее Вы можете ознакомиться с ним по данной ссылке Соглашение о неразглашении . В Федеральном законе РФ 98-ФЗ не оговаривается обязательный формат такого соглашения. Зачастую организации прописывают в соглашении подробности о доступе к данным.

Михаил Романов 28 ноября 2015 14:49

4. По поводу похищения данных (втором мифе) Сконцентрировать данные в облаке и организовать их защиту – значит получить более безопасную и контролируемую среду по сравнению с офисной, где вся информация распределена по рабочим станциям, мобильным устройствам и филиалам компании. Я не понял, за счет чего вы получили "более безопасную и контролируемую среду". Разве от переноса части корпоративных систем в облако информация перестанет быть "распределена по рабочим станциям, мобильным устройствам и филиалам компании"? Если же вы намекаете централизацию ИТ-сервисов как таковую, то всё равно не понятно - какая разница: разворачиваете вы системы в облаке или в собственном data center?

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

 

Михаил Романов 28 ноября 2015 14:49

5. По поводу переноса на резервную площадку: Рекомендации: инфраструктура провайдера должна позволять переносить мощности клиента на резервное оборудование в случае недоступности основного Как именно должна соблюдаться ваша рекомендация? Если вы имеете в виду, что провайдер должен позволять вам бесплатно занять другие сервера взамен утраченных, то это естественная процедура и есть практически у всех (исключая самых упоротых и "бюджетных"). Но это, простите, ничем не лучше, чем иметь резервные средства для переключения на "запасного" поставщика - вы всё равно будете развертывать свои системы заново (выигрышь будет равзе что в случае, когда "изъятие" коснулось лишь части ваших систем. И да, сразу спрошу - а как вы предлагаете тестировать данную возможность (дабы убедиться, что у провайдера она реально есть, а не просто декларируется)?

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

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

Тестировать изъятие оборудования - не выполнимая задача. Тут мы должны доверять провайдеру, либо попросить продемонстрировать наличие свободных резервных ресурсов.

 

Михаил Романов 28 ноября 2015 14:49

6. Про передачу по интернет-каналу Рекомендации: необходимо использовать те облачные сервисы, которые обеспечивают своим пользователям защиту передаваемых данных (VPN-соединение, HTTPS и прочие защищенные протоколы передачи). Скажите, а вы много видели поставщиков, которые не предоставляют что-то из перечисленного (остобенно в случае IaaS - где вам дается, по сути, "чистая" машина, на которой вы вольны устанавливать всё, что вам заблагороссудится)? При этом, вы почему-то обошли вниманием тот факт, что перехват данных, это не единственная потенциальная проблема, вызванная необходимостью работы через внешнюю сеть - для того, чтобы парализовать работу компании достаточно нарушения работы канала до поставщика, хоть на стороне клиента (проблемы у интернет-провайдера), хоть на стороне поставщика (DDoS-атака).

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

Защита от DDoS-атак актуальна всегда и везде. Способы защиты от DDoS - это материал для отдельной большой статьи. Умышленно эту тему пропустил.

Михаил Романов 28 ноября 2015 14:49

7. Про ограничения ресурсов провайдера   Рекомендации: уточните у провайдера, каким объемом ресурсов он фактически располагает. Запросите экскурсию в ЦОД провайдера, если есть такая возможность. Во-первых, не очень понятно, что вам даст осмотр ЦОДа в плане оценки ресурсов. Вы будете считать количество стоек и проверять соответствие их характеристик заявленным? Или что? А во-вторых, значение имеют не номинально имеющиеся ресурсы, а процент их фактической загрузки (в смысле, какая вам разница будет у провайдера 1 на 100% загруженный сервер или 1000), а это вам может сказать только сам провайдер. И прогноз по её росту, а это вам вообще врятли кто-то скажет.   Ну если говорить в общем по статье я не увидел в статье ни ответа на вопрос из заголовка, ни убедительных доводов для самостоятельного принятия решения.

Как минимум стоит узнать, каким количеством ЦОД располагает провайдер, минимально необходимо наличие 2х ЦОД (основной и резервный). Идеально, если провайдер располагает сетью связанных ЦОД, между которыми производится перераспределение нагрузки.

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

И, конечно же, изучить отзывы о конкретном ЦОД, и если есть такая возможность, то связаться с текущими клиентами ЦОД и услышать их рекомендации.

 

Вадим Майшев 02 декабря 2015 г. 17:06  
Все верно, данные в защищенном облаке должны шифроваться.

Я сказал несколько другое: "Защищенным облаком может быть только облако, в котором все хранится только в зашифрованном виде."

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

Защита канала VPN/TLS не защищает данные от сервера. Если сервер свой, вопросов нет, но тут сервер контролируется хостингом. Данные до передачи по каналу должны быть зашифрованы. 

Действительно, SSL-сертификаты бывают разные. Например, у этого сервера он замечательный.

 

Андрей Ардашев 03 декабря 2015 г. 15:50  
Вадим Майшев 02 декабря 2015 17:06
 Данные до передачи по каналу должны быть зашифрованы.  

Это идеальный случай, не каждый сервис может обеспечить такую возможность.

В случае, если имеется облачный сервис с нативным клиентом, то в большинстве случаев данные будут шифроваться перед передачей.

 

 

Сейчас обсуждают
Больше комментариев