Файл: Защита информации при использовании облачных сервисов.pdf

19
В качестве стандартных методов защиты рекомендуется применять специализированные продукты для виртуальных сред, интеграцию хост- серверов со службой каталога Active Directory, использование политик сложности и устаревания паролей, а также стандартизацию процедур доступа к управляющим средствам хост-сервера, применять встроенный брандмауэр хоста виртуализации.
Также возможно отключение таких часто неиспользуемых служб как, например, веб-доступ к серверу виртуализации.
2.1.2 Потеря и утечка данных
С момента появления данных в облаке, средства компании по предотвращению утечки данных считаются недействительными, так как уже не могут помочь в защите конфиденциальности этих данных. При этом, в большинстве случаев, компания даже не имеет возможности прямого контроля над сохранением безопасности своих данных не только в общедоступном облаке, но и в таких моделях предоставления услуг как «программное обеспечение как сервис» (SaaS) и «платформа как сервис (PaaS)»[11].
Для предотвращения утечки информации в облачных сервисах существует множество решений и готовых продуктов, но они в основном направлены на обеспечение целостности и доступности данных и не подходят для реализации защиты. Кроме того, эти решения не подходят для сред, где пользователь не имеет доступа к управлению инфраструктурой.
Между тем основой предотвращения утечки информации является применение доверенных систем хранения и транспортирования данных.
Прежде всего, от поставщика требуется использование высоконадежного шифрования как во время хранения, так и во время передачи материала. Также необходимо иметь заверенное соглашение, в котором будут четко определены роли провайдера и потребителя в обеспечении безопасности данных, и условия предоставления сервиса. Помимо этого контракт должен содержать требование к поставщику услуг облака об уничтожении данных, хранящихся на

20 постоянных носителях, перед их освобождением в пул. В тоже время согласно требованиям стандарта PCI DSS, необходимым является наличие должным образом сконфигурированного межсетевого экрана Web-приложений для защиты последних от разнообразных атак, а также проведение испытания проникновением, чтобы проверить защиту от нежелательного доступа всех используемых компанией приложений.
Наконец, на стороне организации требуется наличие соответствующих политик безопасности. Компании, опасающиеся утечки информации, должны иметь действующие политики классификации данных и установления стандартов относительно порядка обращения с данными различного уровня конфиденциальности, которые могут оказаться абсолютно не предназначенными для хранения в облаке.
2.1.3 Незащищенные интерфейсы API
Для того чтобы клиентам было удобно взаимодействовать с облачными сервисами, поставщики услуг часто предоставляют интерфейсы прикладного программирования (API), которые могут быть применимы для управления и мониторинга облака. Поэтому в большей степени безопасность использования облачных услуг зависит от того, насколько качественно защищены данные интерфейсы API.
Серьезными угрозами безопасности в данном случае являются функции осуществления анонимного доступа, открытые способы аутентификации и многократное использование паролей, а также устаревшие средства контроля доступа и авторизации[12].
Кроме того, интерфейсы API, разработанные сторонними организациями для предоставления клиентам дополнительных возможностей использования облачных сервисов, не всегда отвечают требованиям безопасности и подвергаются детальному анализу, или даже могут содержать скрытые

21 функции передачи данных стороннему лицу. А это повышает уровень риска нарушения конфиденциальности.
Во избежание подобных проблем следует использовать только приложения, предоставляемые или проверенные поставщиком облачных услуг, а также удостовериться в том, что провайдер делает все необходимое для защиты таких интерфейсов API. Кроме того организация должна провести тщательную проверку средств аутентификации и доступа, чтобы быть уверенной в наличии шифрования данных при передаче. А так же убедиться, что используются только заявленные в договоре интерфейсы программирования.
2.1.4 Похищение и несанкционированное использование учетных записей
До настоящего времени были рассмотрены только уязвимости, борьба с которыми возлагается на плечи поставщика облачных услуг. Но обеспечение безопасности учетных записей пользователей в равной доле зависит и от провайдера облачных систем и от потребителя. Потому что уязвимости программного обеспечения, делающие возможным перехват учетной информации пользователя, не являются самым распространенным способом кражи аутентификационных данных.
В большинстве случаев, чтобы завладеть учетной информацией пользователей, злоумышленники используют фишинговые атаки, вредоносное программное обеспечение и социальную инженерию. А так как люди часто используют одни и те же имя пользователя и пароль для получения различных услуг, то только облегчают хакерам поиск аутентификационной информации. С момента получения злоумышленником учетных данных пользователя, под угрозу ставиться не только целостность и конфиденциальность данных, хранящихся в облаке, но и репутация компании, так как правонарушители могут использовать полученную информацию для проведения атак на другие организации[13].

22
Поэтому от организации требуется не только понимание политик безопасности поставщика облака, но и осуществление упреждающего мониторинга пользования облачными сервисами для отслеживания несанкционированного доступа и несанкционированной активности.
Также применение политик со стороны компании, предусматривающих использование уникальных учетных данных для входа в систему и надежных паролей, помогает предотвратить уязвимости, связанные с многократным использованием пользовательской информации. Еще больше уменьшить вероятность атак подобного типа помогают методы двухфакторной аутентификации.
2.1.5 Угрозы со стороны инсайдеров
Как правило, компании тратят очень много средств на установку систем защиты с разграничением доступа пользователям и проверку благонадежности сотрудников. Но когда речь заходит о действиях персонала со стороны поставщика облачных услуг и о том, как регламентированы их действия, прозрачность процессов и процедур, является недостаточной.
Передача управления сервисами поставщику облачных сервисов означает отсутствие у клиента представления о том, кто имеет доступ (физический и виртуальный) к ресурсам организации. Информация о контроле сотрудников, анализе и соблюдении политик безопасности, так или иначе, не является доступной для пользователей. А в то же время возможность работы с засекреченной информацией является очень привлекательной для хакеров и корпоративных шпионов, так как получение контроля над облачным сервисом предлагает злоумышленнику такие конфиденциальные данные, как объем продаж и прибыль компании, которые могут быть проданы им с незначительной долей риска обнаружения или вообще без такового.
Основной мерой защиты от вредоносной инсайдерской деятельности со стороны поставщика услуг является осведомленность о том, какие меры

23 контроля сотрудников предпринимаются провайдером, а также какие действия будут предприняты в случае нарушения защиты и утечки информации. Если сроки или процесс оповещения являются неприемлемыми, следует поискать какого-либо другого поставщика услуг.
2.2 Методы защиты
После рассмотрения существующих угроз в сфере облачных вычислений можно выделить несколько наиболее распространенных решений возникающих проблем. Проанализировав опубликованную по данному вопросу информацию и опираясь на методы защиты, выбранные организацией Cloud Security Alliance
(CSA), было выделено четыре метода обеспечения безопасности информации в среде облачных технологий: шифрование, защита данных при передаче, аутентификация, изоляция пользователей.
2.2.1 Защита данных при передаче
Основным отличием облачных сервисов от обычных центров обработки данных является удобство доступа пользователя к ресурсам приложения в любой момент, из любого места и с любого устройства, имеющего доступ к сети интернет. Но помимо отдельных пользователей к облачной системе могут подключать свою локальную инфраструктуру целые компании. При этом и те, и другие должны быть абсолютно уверены в безопасной доставке своих данных до облачного сервиса. Поэтому рассмотрим возможные способы и варианты безопасного доступа с двух сторон.
Подключение конечных пользователей к облачным сервисам
Для подключения отдельных пользователей в настоящее время имеется несколько вариантов подключения к облачным сервисам, отличающихся друг от друга не только настройкой и установкой, но и удобством использования.

24
Удаленный рабочий стол - это инструмент удаленного доступа к рабочему месту созданный на основе проприетарного протокола прикладного уровня RDP (Remote Desktop Protocol). На данный момент существует множество клиентов для наиболее популярных операционных систем, с помощью которых пользователь подключается к удаленному рабочему столу и может запускать развернутые на сервере терминалов приложения, а также может конфигурировать параметры доступа и системы. Кроме того RDP клиент поддерживает функцию обмена данными между локальным компьютером и удаленным рабочим столом.
2) Удаленные приложения служб терминалов (RemoteApp)
Это решение является разновидностью рассмотренного выше варианта.
Принципиальное отличие заключается только в том, что при доступе к удаленному рабочему столу пользователь имеет доступ к целой операционной системе и установленным на ней программам, а RemoteApp предназначен для доступа к конкретному приложению, интегрированному с рабочей станцией пользователя, но фактически располагающемуся на удаленном сервере.
Средствами RemoteApp происходит подключение к данному серверу, авторизация и запуск программы, создавая видимость локально установленного приложения.
3) Веб-доступ к службам терминалов
Этот способ помогает осуществить доступ как к удаленному рабочему столу, так и к отдельному приложению посредством браузера. Для этого пользователю необходимо авторизоваться на веб-странице поставщика услуги.
4) Подключение по VPN
VPN - это виртуальная частная сеть, позволяющая обеспечить несколько надежных интернет соединений, используя различные средства криптографии.
Существует два типа VPN-туннелей:

Remote access VPN - это защищенный туннель, организованный между приложением на компьютере клиента и каким-либо устройством (например,

25 маршрутизатором), расположенном в облаке хостинг-провайдера. Для реализации данного типа доступа пользователю необходимо запустить ярлык
VPN на своей рабочей станции и ввести свои верительные данные. При успешной авторизации пользователь попадает в сеть виртуального удаленного офиса в облаке и может использовать ресурсы так, как если бы он находился непосредственно в офисе компании.

Site-to-siteVPN— это защищенный туннель, организованный между двумя устройствами пользователей, расположенными в одной локальной сети.
Поэтому не требуется устанавливать на компьютерах какое-либо специальное программное обеспечения.Данный тип туннель применяется, если количество пользователей в компании, которым необходим доступ к ресурсам файлового сервера, достаточно велико. В этом случае необходимо непосредственно в офисе компании дополнительно развернуть VPN-сервер и реализовать подключение Site-to-Site VPN на уровне VPN-сервера в облаке и VPN-сервера в офисе компании.
5) DirectAccess
Помимо стандартных реализаций VPN существует технология
DirectAccess, основанная на базе Microsoft. Она позволяет реализовать возможность удаленного доступа к ресурсам разворачивая туннель до сервера
DirectAccess и благодаря нему получая доступ ко всей сети. При этом пользователю не нужно предпринимать никаких дополнительных действий.
Даже если связь с Интернетом будет потеряна на какое-то время, туннель самостоятельно восстановится.
6) VDI (виртуализация рабочих столов)
На сегодняшний день виртуальная инфраструктура рабочих столов (VDI,
Virtual Desktop Infrastructure) реализована на многих облачных площадках корпоративных IaaS-провайдеров и позволяет централизовать рабочие станции пользователей на серверах виртуализации, создав при этом единую точку управления, развертывания и обслуживания. Для реализации данной

26 технологии со стороны клиента требуется наличие интернет-соединения и рабочей станции. На практике выделяется сервер в облаке IaaS-провайдера, на который устанавливается гипервизор, а на нем разворачиваются отдельные виртуальные машины. На конечном устройстве пользователя запускается программа-клиент и происходит подключение к инфраструктуре.
Подключение локальной инфраструктуры компании к
IaaS- инфраструктуре в облаке
Зачастую многие мелкие и даже средние компании не имеют своей локальной ИТ-инфраструктуры, предпочитая при этом развертывание всех необходимых для бизнеса решений и сервисов в облаке IaaS-провайдера. Такой подход экономически оправдан, выгоден и удобен.
Существует несколько возможных вариантов подключения локальной инфраструктуры компании к IaaS-инфраструктуре в облаке:

аренда выделенного канала и подключение к ЦОД для доступа к облаку;

проброс своего кабеля до ЦОД;

использование точек обмена трафиком.
Рассмотрим каждый из вариантов более подробно.
1)Аренда выделенного канала и подключение к ЦОД для доступа к облаку
В настоящее время очень популярен вариант соединения внутренней сети заказчика с сетью в облаке IaaS-провайдера. Такой сценарий часто именуют гибридным облаком, так как заказчик имеет свои собственные ресурсы, а площадка
IaaS-провайдер предоставляет только дополнительную вычислительную мощность. На физическом уровне данное решение представляет собой использование двух выделенных каналов провайдера, работающих в режиме автоматического переключения в случае падения одного из них. Как правило, такой канал связи предоставляется на основе собственной

27 оптоволоконной сети провайдера с возможностью подписания соглашения об уровне обслуживания, регламентирующего гарантии соблюдения технических характеристик канала. Несомненным плюсом данного метода является в его относительная дешевизна по сравнению с вариантом, когда заказчик пробрасывал бы свой собственный кабель. При этом провайдер, как правило, дает гарантию высокой плотности покрытия, а также безопасности и надежности арендуемых каналов, включая возможность резерва емкости при росте канала.
2)Проброс своего кабеля до ЦОД
Внутренняя сеть заказчика и сеть в облаке IaaS-провайдера также могут быть соединены пробросом собственного кабеля клиента до необходимого центра обработки данных. Такой метод является менее экономичным, по сравнению с предыдущим. Поэтому компании, которые нуждаются в высокоскоростных телекоммуникационных каналах, в большинстве случаев предпочли бы ранее рассмотренный нами вариант: аренду каналов или выкуп оптических волокон в уже проложенной линии связи. Однако организации, предъявляющие повышенные требования к безопасности и эксплуатационным показателям канала связи вынуждены сделать выбор в пользу прокладки собственной оптической линии.
3)Использование точек обмена трафиком
Этот способ прокладывания канала от организации к IaaS-провайдеру является удешевленной версией метода, рассмотренного ранее. Его суть заключается в том, что кабель прокладывается не до центра обработки данных облачного провайдера напрямую, а до коммутационного оборудования, размещенного IaaS-провайдером на площадках, где располагаются точки обмена трафиком. Точка обмена трафиком — это место, где осуществляется прямой обмен трафиком между интернет-операторами, минуя сети сторонних провайдеров. Все ее участники имеют возможность построить соединения друг с другом, задействовав при этом лишь один порт. Благодаря прямым пирингам,