Основные способы обеспечения безопасности данных в облаках

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

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

Но перед этим интересная статистика:

• 64% компаний считают облачные системы более безопасными, чем локальные системы;
• 75% предпринимают дополнительные меры для обеспечения безопасности;
• 61% шифруют свои данные;
• 52% ввели политику управления доступом к информационным системам;
• 48% проводят регулярные проверки информационных систем на соответствие требованиям безопасности.

Шифрование

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

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

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

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

Одним из таких сервисов является Boxcryptor. Главное достоинство Boxcryptor — поддержка популярных облачных хранилищ, таких как Dropbox, Google Drive, OneDrive, Box, Amazon, iCloud Drive, Яндекс.Диск и Mail.ru. Также сервис поддерживает все популярные платформы, включая мобильные операционные системы iOS и Android. У продукта есть бесплатная версия, но она имеет некоторые ограничения. Например, можно работать только с одним облаком. Платная же версия позволяет шифровать имена файлов и работать с неограниченным количеством облачных провайдеров.

Мониторинг инфраструктуры

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

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

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

• Executive Reports (краткий отчет о безопасности для руководителей, включающий количество обнаруженных угроз или нарушений правил за определенный период времени);
• Interactive Reports (интерактивная отчетность);
• Scheduled Reports (регулярное распространение стандартных и настраиваемых отчетов);
• Company Risk Score Report (расчет оценки рисков для компании, входящий в пакет Business и Transformation, и доступный за отдельную плату для пакета Professional);
• Industry Peer Comparison (сравнительное сопоставление эффективности использования Zscaler в вашей организации и в других организаций в вашей отрасли);
• System Audit Report (системный отчет о статусе туннелей GRE, файлов PAC и т.д. Если есть проблемы, в отчете будут приведены рекомендации по их устранению);
• Security Policy Audit Report (отчет о проверке политики безопасности).

Ограничение доступа к данным

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

В последнее время получила широкое распространение ролевая модель безопасности (также называемая ролевым контролем доступа). Эта модель основана на идентификации пользователей при помощи логина. Когда пользователь идентифицирован, ему автоматически назначаются роли и решения.

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

Контроль доступа, базирующийся на ролях (Role Based Access Control, RBAC), рассматривает всю информацию, как принадлежащую данной организации. В такой системе пользователи не могут передавать права на доступ к информации другим пользователям. Эта система основывается на принятии решения о доступе на основе информации о функции, которую пользователь выполняет внутри данной организации на основании своей роли.

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

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

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

Облачные системы, такие как Amazon EC2, широко применяют RBAC для точной настройки доступа конечных пользователей к ресурсам. Microsoft Azure также использует RBAC для управления доступом к облачным ресурсам. Поэтому в качестве примера приведем некоторые действия, которые можно выполнить при помощи RBAC:

• предоставление одному пользователю разрешения на управление виртуальными машинами в подписке, а другому — на управление виртуальными сетями;
• предоставление группе DBA разрешения на управление базами данных SQL в подписке;
• предоставление пользователю разрешения на управление всеми ресурсами в группе ресурсов, включая виртуальные машины, веб-сайты и подсети.

Резервное копирование данных

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

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

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

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

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

План аварийного восстановления

План аварийного восстановления (Disaster Recovery Plan) позволяет обезопасить бизнес от сбоев в работе ИТ-инфраструктуры и возможной потери данных.

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