Мнимая безопасность платформ

НЕСМОТРЯ НА ТО ЧТО ПОТРЕБИТЕЛЬ облачных услуг по модели PaaS привязан к арендованной платформе, где выбор средств защиты информации ограничен и принадлежит облачному провайдеру, у заказчика зачастую остается возможность настройки и управления функциями защиты приложений Источник: iStock

Пользователи все чаще начинают применять в повседневной деятельности облачные решения, арендуя не только инфраструктуру, о защите которой мы уже писали в статье «Заказчикам IaaS требуется защита» («Сети», № 4, 2013), но и платформу, то есть уже готовую среду исполнения, для которой можно самостоятельно написать приложения или приобрести уже готовые компоненты из магазина.

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

Организационные риски

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

«Как и у любого сервиса, у PaaS есть несомненные плюсы и есть минусы, — отмечает Чирков, — каждый потребитель вправе принимать или не принимать риски при переходе в облако. При пересмотре собственных процессов обеспечения ИБ, тщательной проработке модели угроз и требований по ИБ, юридическом закреплении схем взаимодействия с облачным провайдером арендованная платформа может быть не менее защищенной, чем ресурс, находящийся в корпоративной сети». И уже сам выбор оператора платформы несет в себе определенные риски, которые можно назвать организационными. По различным признакам их можно объединить в несколько категорий.

• Привязка к оператору. Один из основных организационных рисков — это привязка к оператору, когда у клиента нет возможности по тем или иным причинам отказаться от услуг конкретной компании и перейти на другую платформу. Чтобы не попасть в такую ситуацию, стоит проверить, насколько предлагаемая платформа может быть отчуждаема и можно ли ее установить в своей компании. Вот как ситуацию комментирует Александр Демидов, руководитель направления арендных решений «1С-Битрикс»: «Ключевая проблема, которая может возникнуть, — это привязка к оператору платформы. Единожды выбрав провайдера, клиентам потом сложно перейти к другому, так как нет единства между ними. Достаточно проблематично мигрировать к новым провайдерам, например используя платформу Windows Azure или Google App Engine». Аналогичного мнения придерживается и Александр Большев, аудитор ИБ компании Digital Security: «Основной вопрос, который должен возникнуть у любого пользователя PaaS, — насколько он доверяет вендору. Список рисков при использовании PaaS зависит как раз от вендора, и именно вендор, предоставляющий платформу, может минимизировать эти риски. Поэтому выбор вендора — ключевой момент, определяющий, насколько безопасной будет ваша инфраструктура, построенная по модели PaaS». Так что клиентам, прежде чем выбирать платформу, стоит ее заранее оценить, в том числе и с точки зрения безопасности используемых в ней приложений. По идее именно услуги безопасности и должны являться конкурентным преимуществом провайдера PaaS, однако пока для российского рынка это не так.
• Соответствие законодательству. Для России важным требованием к провайдеру PaaS является соблюдение им требований российского законодательства. В частности, серьезные ограничения налагает закон «О персональных данных», соблюдение которого при пользовании сервисами PaaS может быть затруднено дополнительными требованиями по сертификации защитных решений. Впрочем, требования по защите могут быть и у других регуляторов, особенно у отраслевых. Поэтому, принимая решение о выборе провайдера, следует заранее проработать вопросы соответствия предлагаемой платформы законодательной базе для конкретной компании. Причем перенос данных в иностранный ЦОД или облако не всегда решает проблему исполнения законодательства, поскольку в этом случае могут выдвигаться дополнительные требования, например по трансграничной передаче данных. В частности, закон «О персональных данных» ограничивает набор стран, куда можно передавать обрабатываемые данные.
• Управленческие проблемы. Сложности могут возникнуть не только с аппаратурой, но и с обслуживающей компанией. Сотрудники провайдера не всегда обладают достаточным опытом и могут оперативно решать поставленные перед ними задачи обеспечения безопасности. Отдельной проблемой являются утечки данных клиентов со стороны обслуживающего персонала, который может получить доступ к очень важным данным, обрабатываемым на платформе, или вмешаться в работу приложений. Основным критерием для оценки этого риска является репутация провайдера и используемой им платформы PaaS. Чем дольше провайдер или разработчик платформы находятся на рынке, чем больше у них клиентов, положительно оценивающих их деятельность, и чем крупнее их бизнес, тем ниже вероятность возникновения проблем с информационной безопасностью.

Следует отметить, что провайдеров PaaS можно условно разделить на три группы: крупные западные производители программного обеспечения, такие как Microsoft или IBM; российские интеграторы, установившие у себя необходимый стек продуктов («Корус Консалтинг», «Крок»); российские разработчики приложений («1С-Битрикс»). Также можно выделить два типа платформ: открытые, построенные на Linux, MySQL, PHP и других открытых продуктах, и закрытые, такие как облака Microsoft Azure. Если при пользовании открытыми продуктами переносимость приложений достигается простым повторением конфигурации, то для коммерческих продуктов необходимо воссоздать облачную конфигурацию в корпоративной среде из набора продуктов производителя. Например, компания «1С-Битрикс» позволяет переносить приложения из облачной инфраструктуры «Битрикс24» на локально установленный корпоративный портал предприятия собственной разработки. Приложения, развернутые в облаке Microsoft, можно перенести на локально установленные SharePoint, Exchange и другие продукты из набора Microsoft. Такую миграцию от провайдера к собственной инфраструктуре можно рассматривать как защиту от организационных рисков. Правда, зачастую отказ от публичного PaaS в пользу частного облака оказыватся достаточно затратным по времени и ресурсам мероприятием.

Технические риски

Как правило, провайдеры PaaS предоставляют клиентам возможность писать приложения на собственном сценарном языке, а также могут обеспечивать такие сервисы безопасности, как аутентификация пользователей и защита от DDoS-атак. Однако сами базовые компоненты, на которых работает платформа, также могут быть уязвимыми для нападений извне. Сергей Рыжиков, генеральный директор «1С-Битрикс», предупреждает: часто хакеры атакуют не платформы, а базовое программное обеспечение, на котором те работают. Поэтому провайдер должен оградить предлагаемую платформу от подобных атак. Если не учитывать атаки на базовые компоненты платформы, то можно выделить следующие механизмы защиты PaaS:

• Защита от DDoS-атак. Защиту платформы от атак, направленных на остановку приложений, должны выполнять инфраструктурные элементы IaaS. Однако и на уровне платформы также нужно предусмотреть соответствующие средства защиты. Только действовать они должны уже не на уровне инфраструктуры, а ликвидировать уязвимости платформы приложений. Есть атаки, нацеленные не на банальное «затопление» сервера запросами, а использующие конкретную брешь в платформе. В этом случае атака может содержать не очень большой поток данных, но приводить к плачевным результатам: зацикливанию платформы, замедлению обработки обычных запросов или даже выводу из строя некоторых важных для функционирования системы элементов. Примером подобных атак можно считать массовый перебор паролей для администраторов CMS-систем Joomla и Wordpress, который был зафиксирован в августе и сентябре этого года.
• Экран уровня приложений. Для защиты от атак на уязвимости платформы хорошо работает инструмент, который называется «экран уровня приложений». Этот компонент платформы анализирует входящий и исходящий трафик, блокируя попытки эксплуатации известных уязвимостей, таких как SQL- или PHP-инъекции. Впрочем, если платформа имеет собственный сценарный язык программирования, то систему нужно защищать от попыток пользователей вставить фрагменты этого языка в данные. В исходящем потоке данных также следует фильтровать определенные конструкции, особенно если данные были переданы самим пользователем, — это признак XSS-нападения, при котором пользователю в URL внедряется исполнимый в его браузере код. То есть с помощью экрана уровня приложений пользователи защищаются от ошибок программирования: их вполне могут допускать внешние разработчики. В частности, такой механизм встроен в CMS-платформу «1С-Битрикс».
• Анализаторы сценариев. Более эффективным инструментом защиты платформы от уязвимостей являются специальные анализаторы исходных кодов для сценарных языков платформы. Они позволяют проверить загружаемый в платформу код на наличие в нем типичных ошибок программирования, а иногда и специально вставленных закладок. Сейчас подобные анализаторы начали появляться на рынке в том числе и для исходных текстов на не очень распространенных языках программирования. Правильно перед внесением любых изменений в код приложения проверить его на подобном анализаторе. На рынке есть как свободно распространяемые анализаторы с коммерческими наборами правил для анализа, так и коммерческие сканеры кодов. Например, компания ApperCut предлагает подобный облачный сканер для самых разнообразных языков программирования, включая встроенные сценарии SalesForce, SAP и Oracle. «После изменения Oracle политики лицензирования Java многие производители платформ начали разрабатывать собственные языки сценариев», — отметил Рустем Хайретдинов, генеральный директор ApperCut.
• CMS-антивирус. Сейчас популярные платформы CMS (Content Management System) используются для распространения вредоносных программ. Делается это так: взламывается сервер со свободно распространяемой CMS и в нее инсталлируется модуль, который вставляет в коды страниц ссылки на вредоносные ресурсы. Есть также модули для удаленного исполнения любых команд на сервере, которые могут быть встроены, например, в тему сайта. Разработчики таких вредоносных вставок используют различные методы скрытия своего кода от администратора. Поэтому администраторам CMS стоит использовать специальные сканеры кодов, которые в уже развернутом сайте обнаруживают подобные вредоносные фрагменты. Также есть инструменты с открытым исходным кодом, однако не совсем понятно, насколько быстро в них обновляются сигнатуры вредоносных вставок.
• Сканеры уязвимостей. Для проверки выстроенной вокруг платформы системы защиты стоит использовать специальные сканеры веб-уязвимостей, которые в автоматическом режиме проводят так называемые стресс-тесты. Они снаружи проверяют платформу вместе со всеми установленными на нее приложениями. Такие проверки также необходимо проводить, хотя они и нагружают платформу и приложения непродуктивными запросами.
• Аутентификация. Большинство платформ предлагают только такой простой способ аутентификации, как пароли. Этого вполне достаточно для информационных порталов, но уже при использовании CRM, ERP или других более критических систем лучше пользоваться более защищенным средствами аутентификации. В этой сфере уже разработано много инструментов: генераторы одноразовых паролей с пересылкой их по SMS, аппаратные токены для считывания пароля с экрана компьютера с помощью специальной кодировки, USB-ключи и множество других инструментов. Важно, чтобы арендованная платформа позволяла интегрироваться с подобным защищенными способами аутентификации и не требовала для этого слишком больших дополнительных расходов.
• API платформы. Пользователь часто не знает, на какой именно операционной системе и базе данных работает платформа, хакеры тем не менее могут атаковать эти базовые элементы информационной системы. То есть взломщики могут атаковать не саму платформу, а через нее — базовые компоненты. Опасность такой атаки зависит от набора интерфейсов, которые предоставляет платформа для приложений, поскольку именно через них хакеры в конце концов и нападут на операционную систему или базу данных. Поэтому платформа должна иметь как можно меньший выбор инструментов прямого доступа к базовым элементам и всячески защищаться от попыток использования подобного прямого обращения.

Заключение

Пока российские клиенты не осознали необходимость использовать перечисленные инструменты защиты в своей работе и тем более не требуют внедрения их от провайдеров PaaS. Даже простая защита пароля от перебора (например, отправка через SMS одноразовых паролей на мобильный телефон администратора) не востребованы. По словам Андрея Шварцкопфа, генерального директора PaaS-провайдера Rusonyx, во время проведения массовой атаки с подбором паролей для Wordpress и Joomla пришлось устанавливать дополнительную проверку — после ввода пароля администратора клиентского сайта просто просили ввести слово Admin. «Обойти подобную защиту достаточно просто, однако специально под нас разработчики роботов не будут их подстраивать», — пояснил Шварцкопф. А если бы у администраторов был одноразовый пароль, то никакой переделки не потребовалось бы. Сами клиенты не хотят пользоваться дополнительными средствами защиты и при этом не доверяют облачным технологиям именно по причине их небезопасности. Получается замкнутый круг: провайдеры не внедряют механизмы защиты, поскольку считают их невостребованными для пользователей, а пользователи просто не переходят на модель PaaS, считая ее незащищенной.