Защищаем данные в облаке

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

О безопасности в облаке

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

То есть просто заплатил, арендовал и работай, если ресурсов сервера станет недостаточно их также легко можно увеличить. Большую роль здесь играет успех виртуализации, которая по данным v-index.com достигла уже 38.9%. Единственное, что остается не выясненным это вопрос безопасности. Самое интересно, что проблема кроется в самом принципе организации данных. Ранее пользователь самостоятельно подбирал и настраивал приложение, организовывал все сопутствующие вопросы, в том числе защиту и мероприятия по резервному копированию, беспокоясь о сохранности и доступности данных. Теперь все это отдано провайдеру услуг в виде SaaS (Software as a Service, приложение как сервис) или PaaS (Platform as a Service, платформа как услуга), и как у него все организовано, часто приходится только догадываться. Поэтому организациям приходится полностью доверять поставщику, который правда не всегда может гарантировать отсутствие неприятностей. В лицензиях они так и пишут — защита проблема клиента.
Именно риск потерять разом все данные, помноженный на возможность утечки конфиденциальной информации, останавливает многих потенциальных пользователей от внедрения SaaS. К слову о рисках, специалисты безопасности при разработке системы защиты оперируют именно этим понятием. То есть если данные никому не нужны то и смысла строить баррикады нет, достаточно замка.
Конечно если сервис предоставляется такими монстрами как Google или Amazon, обладающих большими ресурсами и расположенные “за бугром”, то беспокоиться о том что в датацентр ворвутся люди в масках и конфискуют все серверы или жесткий диск сопрет неблагонадежный сотрудник, наверное не стоит. Как раз наоборот человеки из «маски шоу» должны знать что данные находятся в облаках и где находятся сервера, поверьте не каждый оперативник об этом задумывается ;). То есть в этом варианты мы можем сохранить данные и хотя бы частично возобновить работу подключившись с другого офиса. В любом случае риски одинаковы, да и в некоторые местные ЦОД попасть не так то и просто.

Ричард Столлман (gnu.org/philosophy/who-does-that-server-really-serve.html) характеризует облачную технологию как эквивалент всеобщего шпионского ПО и большой «черной двери» так как дает власть над пользователем. Суть обращения сводится к призыву: следует избегать SaaS-услуг и стараться удержать обработку данных в своих руках.

Именитые игроки на рынке, защищены на порядок лучше, чем серверная в небольшой организации, за безопасностью следит целая служба, компания заботится о своем имидже и поэтому проводит весь комплекс мероприятий. К тому же если компания поставщик услуг давно работает на рынке и забоится о своей репутации, имеет подготовленный персонал (а как иначе удержаться) и она должна вызывать больше доверия, чем вчерашний студент, нанятый на испытательный срок. Добавим, что половина утечек из компаний происходит благодаря инсайдерам.
Если в случае внутреннего сервиса, за его сетевую безопасность полностью отвечает админ, который размещая его в DMZ полностью контролирует весь трафик ограничивая доступ только с доверенных сетей при помощи файервола и другими методами (VPN, /etc/host.allow). В случае DDOS атаки на провайдера или одного из клиентов могут пострадать сразу несколько организаций. Не меньшие проблемы возникнут в случае взлома сервиса. Теперь же эта функция частично переходит к разработчикам сервиса, а в руки штатного админа получаем меньше методов контроля, работающих в случае SaaS вообще на уровне приложений и вряд ли имеющих большую гибкость. И это хорошо, если такие есть. Кроме этого становится на порядок тяжелее управлять правилами местного файервола. Для подготовленного админа и небольшой сети это не проблема. В случае разветвленной сети можно обратить внимание на продукт Security Code TrustAccess (securitycode.ru/products/trustaccess) позволяющий организовать централизованное управление распределенным межсетевым экраном.
Не менее важный вопрос — возможная миграция на другую платформу или сервис. Что делать при смене провайдера, Если инструменты миграции? Ведь зависимость от одного поставщика тоже не всех может устроить. И не обязательно это может быть внеплановое повышение цен не укладывающихся в бюджет, а например недостаточно каких-либо важных функций или невозможность интеграции с текущей инфраструктурой. В случае SaaS здесь проблем наверное больше, так как приложения часто имеют специфическую структуру данных, а вот скачать и перенести ОС в чем то вроде VMware vCloud Director проблем нет.

Аудит в облаке

Еще один важный момент — контроль и аудит всех выполняемых операций над действиями администратора и пользователей. При наличии большого числа сервисов легко напутать с правами. В принципе администратор имеющий все, может навредить в любом варианте (облако или локальная система), всего пару команд и данных нет, аналогично может уйти в небытие и резервные копии. Таких примеров можно привести тысячи, в век виртуализации они уже стали реальностью. Например, по сообщению ComputerWorld администратор одной из компаний обидевшись на работодателя, одним махом удалил почти сотню серверов работающих VMware vSphere.
В случае SaaS ситуация уже не так однозначна. Администратор провайдера может одной командой уничтожить несколько десятков виртуальных машин со всеми данными, админ организации только свой сервис. Виноватым в обоих случаях может оказаться и провайдер, если только он не докажет что данные SaaS компании уничтожены самими админом. Выход из такой ситуации который бы устроил всех — иметь две резервных копии провайдер свою, компания клиент — свою. В этом случае уничтожить сервис будет не так то просто.
Поэтому разграничение доступа и аудит всех событий очень важен, ведь кроме прямого вредительства может быть и кража данных (экспорт на любой внешний источник). В идеале администратор управляет сервером, данные находятся в руках менеджера и за всем этим следит кто-то из секюрити. Единственным на сегодня сертифицированным решением обеспечивающим безопасность виртуальных инфраструктур построенных на продуктах VMware, является vGate R2 (securitycode.ru/products/sn_vmware/vgate_com). В нем реализована автоматическая конфигурация безопасности, мандатная модель управления доступом (каждый может управлять строго своими VM), строгая аутентификация админов, защита средств управления, правила разграничения доступа (на основе ACL и портов), контроль целостности VM, расширенный аудит событий и мониторинг. И четко выделяются две роли имеющие свои функции и возможности: администратор виртуальной инфраструктуры (АВИ) и администратор информационной безопасности (АИБ). Процедура аутентификация для них усилена, АВИ к тому же использует дополнительно программу-агента.

Еще один продукт Novell Cloud Security Service (NCSS, novell.com/products/cloud-security-service) дает возможность легко управлять учетными данными предприятия, реплицируя все изменения в аккаунтах в облако, гарантируя единую базу. Работает NCSS очень просто, служба размещается в локальной сети или облаке и интегрируется со службой аутентификации предприятия (вроде Active Direcory), пользователь который хочет получить данные с SaaS/PaaS/IaaS регистрируется обычным образом, а NCSS генерирует тикет соответствующий требованиям поставщика услуг.
Но не смотря на то, что именно безопасность больше всего беспокоит пользователей многие специалисты считают не менее важными факторами при выборе поставщика SaaS уровень доступности и производительность. Причем эта сторона обоюдная, ведь использование SaaS автоматически означает увеличение нагрузки на внешний канал и зависимость от его стабильности. А значит, что с клиентской стороны необходимо предусмотреть все сопутствующие мероприятия. Хотя упавший канал сегодня уже можно назвать редкостью и ничего не мешает взять запасной у другого провайдера. К тому же отсутствие интернета часто означает, что нормальная работа не возможна в любом случае, а поэтому наличие доступа к облаку абсолютно не играет никакой роли. Зато сотрудники работающие вне офиса, могут получать данные без задержек.

Шифрование данных

Большинство считает, что канал связи и данные размещаемые в облаке лучше шифровать. С обменом данными в SaaS проблем обычно не бывает, провайдеры предоставляют доступ по защищенному протоколу HTTPS, администратору клиента остается лишь следить за сертификатами. А вот как контролировать данные в облаке, если они находятся в открытом виде вопрос очень волнующий, ведь в случае инсайдера у провайдера риск утечки большой. Поэтому многие предпочитают поставщика который обеспечивает шифрование данных, это позволит защитить их от кражи и быть уверенным, что посторонние пользователи не получат к ним доступ. Наиболее оптимальным для передачи ключа и взаимной аутентификации пользователя и серверов облака является криптографиия с открытым ключом.
Технологии могут быть использованы разные. Очень популярна LUKS (The Linux Unified Key Setup, code.google.com/p/cryptsetup), для Linux она реализована в dm-crypt дающем возможность создавать зашифрованные разделы или логические диски.


Также LUKS поддерживает схему безопасной установки ключей TKS1 (Template Key Setup 1), которая позволяет сменить пользовательский ключ, не перешифровывая весь диск, работать с несколькими ключами и обеспечить разделение секретов путем ввода двух ключей. В Windows технология реализована в пакете FreeOTFE (freeotfe.org), который совместим с зашифрованными томами Linux (cryptoloop, dm-crypt), поддерживает двухфакторную аутентификацию с использованием смарт-карты или HSM (Hardware Security Module, модуль безопасности аппаратных средств) используя стандарт PKCS#11.

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

Кроме этого в последних версиях Windows доступна функция шифрования разделов BitLocker или в старых EFS (Encrypted File System).
Хотя необязательно шифровать весь раздел или создавать закрытые контейнеры. Учитывая, что в большинстве случаев информация хранится в СУБД можно зашифровать только соответствующие таблицы, то есть получив к ним доступ инсайдер ничего не может сделать без ключа. Каких либо дополнительных усилий это не потребует, ведь большинство современных СУБД имеет достаточно надежные механизмы, остается лишь только их задействовать. Например в MySQL Reference Manual п.11.13. который так и называется «Encryption and Compression Functions» описано 15 функций, часто достаточно лишь немного модернизировать SQL вызовы в приложении чтобы все происходило автоматически.

> CREATE TABLE md5_tbl (md5_val CHAR(32), ...);
> INSERT INTO md5_tbl (md5_val, ...) VALUES(MD5('abcdef'), ...);

Многие облачные сервисы предлагают механизмы шифрования и API для более удобного доступа к ним. В Windows Azure SDK (microsoft.com/windowsazure/sdk) позволяющем разработчикам использовать сервисы Windows Azure имеется и набор функций обеспечивающих доступ к CSP (Cryptographic Service Providers, провайдер криптографических сервисов).

Но шифрование не всегда решает все проблемы, ведь остаются традиционные атаки и уязвимости которые могут привести к утечке информации — XSS, SQL injection, слабые пароли, социальная инженерия и так далее. Также на сегодняшний день большинство распространенных технологий управления ключами шифрования имеют недостатки. Особенно остро стоит вопрос в управлении ключевой информацией, где их хранить, как использовать (вводить вручную неудобно, да и не совсем безопасно) и как защищать. При наличии большого числа виртуальных машин система шифрования тоже может стать проблемой, ведь нужно четко определить, кому и куда положен доступ и соответственно распределять ключи. Технология должна быть гибкой и не привязана к конкретному провайдеру услуг. Самым популярным решением обеспечивающим шифрование данных и управление ключами является Trend Micro SecureCloud являющися удобной надстройкой над FreeOTFE и другими утилитами, в котором используется специальная технология позволяющая проверять сервера запрашивающие ключи, контролировать доступ к закрытым данным, удаление информации без возможности восстановления.

В случае смены поставщика услуг, все данные переносятся без проблем, поддерживаются Amazon EC2, Eucalyptus и vCloud. Распространяется SecureCloud как коробка так и в виде сервиса.
Еще минус — шифрование/дешифрование будет существенно тормозить виртуальную машину, а что делает если системные ресурсы ограничены.

Заключение

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

Теги: , ,

Понравилась статья? Оставьте комментарий или подпишитесь на RSS рассылку.

Комментарии

Комментариев пока что нет

Оставить комментарий

(required)

(required)