Содержание


Разработка безопасных облачных приложений

Рекомендации по обеспечению безопасности облачных приложений

Comments

Характеристики облачных приложений

Облачные приложения – это очень простые приложения, ориентированные на облачные службы и используемые ими инфраструктуры, что позволяет беспрепятственно и автоматически масштабировать их, наращивая и сокращая ресурсы, обрабатывать отказы и решать многие другие задачи. В отличие от обычных веб-приложений, размещенных в облаке, которые, по существу, представляют собой многоуровневый стек программного обеспечения, развернутый в стеке виртуального оборудования, облачные приложения, как правило, имеют более распределенную модель без запоминания состояния и с использованием служб и акторных моделей (actor models) вычислений. Общее сравнение характеристик традиционных n-уровневых приложений и облачных приложений приведено в таблицах 1 и 2.

Таблица 1. Характеристики N-уровневого приложения
ХарактеристикаОписание
СинхронностьСинхронное взаимодействие «запрос-ответ».
Централизованное хранение состоянияКак правило, состояние хранится в одной базе данных.
КластеризацияВ целях масштабирования использует многочисленные кластеризованные службы, работающие вместе.
Изолированная архитектура компонентовN-уровневые приложения, как правило, состоят из вертикальных изолированных компонентов, так что службы и данные остаются в пределах одной среды.
Таблица 2. Характеристики облачных приложений
ХарактеристикаОписание
Устойчивость к сбоямУстойчивость к сбоям встроена в приложение. Отказы в облачной инфраструктуре обрабатываются гладко, без прерывания обслуживания.
Устойчивы к задержкеВместо прерывания работы/отказа приложения корректно адаптируются к задержке.
БезопасностьПриложения основаны на стандартах безопасности жизненного цикла. Данные, находящиеся покое и в пути, зашифрованы. API-интерфейсы защищены с помощью аутентификации и авторизации.
Независимость от местоположенияПриложения не полагаются на жесткие зависимости, а находят службы динамически.
Эластичное масштабированиеПриложения реагируют на уровень спроса, наращивают и сокращают ресурсы по мере необходимости и между облаками.
КомпонуемостьПриложения потребляют и предоставляют веб-сервисы посредством API, которые можно обнаруживать во время выполнения. Структура состоит из компактных компонентов без запоминания состояния, рассчитанных на масштабирование.
Зависимость от инфраструктурыПриложения не делают никаких предположений по базовой инфраструктуре, используя абстракции по отношению к операционной системе, файловой системе, базе данных и т.п.
Определенная модель пользованияКаждое приложение должно иметь определенную однопользовательскую или многопользовательскую модель.
Чувствительность к пропускной способностиAPI и протоколы приложения могут реагировать на изменение пропускной способности и заторы.
Стоимость и потребление ресурсовПриложение чувствительно к используемой пропускной способности, используемому объему пространства хранения, IP и т.п. Можно установить правила автоматического регулирования, способ управления или нужный размер на основе фактического использования.

Как видно из таблиц 1 и 2, облачные приложения, в отличие от более традиционных приложений с изолированными компонентами, эксплуатируемыми в облаке, используют многочисленные службы и конечные точки. (В разделе Ресурсы в конце этой статьи есть ссылка на документ Open Data Center Alliance «Проектирование облачных приложений».) В результате это может привести к проблемам безопасности, ваши данные или функции приложений могут опираться на сторонние службы, не контролируемые вами. Хотя существует внутренний риск облачных служб, это особенно актуально для облачных приложений, когда данные могут подвергаться угрозе, находясь в состоянии покоя, в пути и в процессе использования. Более того, в случае облачных приложений может оказаться, что вашими данными управляют сторонние организации. У этих партнеров может быть слабая защита, и они могут непреднамеренно допустить утечку данных или подвергнуться атакам злоумышленников, что, к сожалению, случается довольно часто даже с некоторыми из наиболее уважаемых поставщиков облачных приложений и услуг. Другая проблема заключается в том, что даже при использовании SSL может произойти утечка данных, так как они передаются по сети. Особенно если ваши сертификаты или сети партнеров плохо настроены. Утечка данных может произойти и вследствие того, что данные используются в облачной среде, которая может быть взломана, что приведет к утечке ключей шифрования или важной информации. Наконец, ввиду автоматизированной и интегрированной природы облачных приложений они часто бывают уязвимы к атакам на конечные точки API, если доступ к ним не контролируется.

Необходимость шифрования данных в облачных приложениях

За редкими исключениями, одним из наиболее важных активов любой компании являются ее данные. Они могут принимать форму финансовой, конфиденциальной коммерческой, маркетинговой или медицинской информации, интеллектуальной собственности (ИС) и многие другие формы. Потеря данных может отрицательно сказаться на деятельности организации и даже привести к ее прекращению. Кража или публикация этой информации может повредить репутации организации, вызвать юридические проблемы и негативно повлиять на бренд, как видно из недавних атак на Sony Pictures. Таким образом, защита данных может и должна иметь важнейшее значение для бизнеса, будь то стартап с двумя сотрудниками или многонациональная корпорация. Для защиты своих данных в облаке нужно решить много задач — от контроля доступа до укрепления операционных систем. Многочисленные взломы показали, насколько важно предпринять важнейшие шаги, такие как создание правил перемещения данных и доступа к ним и укрепление защиты сети. Но сколько бы мер вы не приняли для защиты своей системы, вероятность того, что кто-то найдет способ обойти ее, сохраняется. Постоянно появляются новые угрозы, от обычных инсайдерских угроз до атак в общенациональном масштабе и фундаментальных пробелов в защите программного обеспечения, которые удивляют даже экспертов по безопасности и позволяют получить полный контроль над системой. Так что, как я уже отмечал, облачные приложения должны иметь встроенную защиту с шифрованием как покоящихся, так и передаваемых данных.

Три состояния шифрования и модель коллективного риска в облаке

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

Уникальные проблемы безопасности облачных приложений заключается в том, что поставщики «инфраструктуры как услуг» (IaaS) и «платформы как услуг» (PaaS) используют модели коллективного риска. Это означает, что ваши партнеры по облаку обычно предоставляют вам защищенный центр обработки данных, некоторую защиту сети, высоконадежные системы хранения и оборудование, а также другие услуги — но при этом ожидают, что вы будете соблюдать определенные требования безопасности. К ним относятся управление реквизитами доступа и их контроль, обнаружение вторжений, мониторинг, укрепление операционных систем, установка исправлений на системы и, конечно, шифрование. Кроме того, в силу модели коллективного риска, так как вы не имеете физического контроля над своей машиной и доступом к ней, существует потенциально повышенный риск взлома вашей системы сотрудниками поставщика или посторонними, которые могут получить физический доступ к системе. Существует также риск (хотя он пока не проявился) атаки или заражения системы другими арендаторами. Таким образом, безопасность облачных приложений диктует необходимость шифрования всех конфиденциальных данных в ваших облачных системах, а также защиту всех передаваемых данных.

Сначала правила, потом технология: нормативное соответствие и контроль

Прежде чем перейти к тому, какие подходы следует использовать для обеспечения безопасности облачных приложений, следует понять, что именно требует защиты в вашей организации, чтобы уяснить и четко определить правила безопасности для ваших приложений. Те же правила должны применяться и к жизненному циклу разработки безопасного программного обеспечения (Secure Software Development Lifecycle - S-SDLC), чтобы не только создавать более безопасные приложения, но и управлять ими на протяжении всего срока их службы. Вот некоторые отправные точки для разработки таких правил.

  1. Заручитесь участием всех основных заинтересованных сторон, которые имеют доступ к вашим системам, от отдела кадров до операционного отдела, финансового отдела и администрации. Часто организации забывают включить те или иные подразделения, что приводит к таким проблемам, как в Sony Pictures, где контракты, содержащие конфиденциальные данные, были доступны в на серверах в незашифрованном виде.
  2. Разработайте правила определения лиц, имеющих доступ к вашей системе, и внедрите надежное решение для управления идентификацией – не только для внутренних пользователей, но и для пользователей внешних служб и конечных точек. Это решение должно поддерживать возможность генерировать журналы доступа и обеспечивать доступ на основе ролей, а также шифрование и управление ключами. Наконец, подумайте о мультитенатности на раннем этапе, поскольку часто даже от приложения с одним арендатором со временем начинает требоваться поддержка мультитенатности.
  3. Решите, кто будет иметь доступ к ключам шифрования на верхнем уровне и где они будут храниться. Хотя способ управления ключами зависит от конкретной реализации системы, с самого сначала нужно хорошо понимать, кто именно должен иметь к ним доступ.
  4. Тщательно рассмотрите, какие нормативные требования необходимо соблюдать: PCI, FISMA, HIPPA, GLBA и т.п. Большинство нормативных документов требует определенного уровня шифрования или диктуют способы управления ключами шифрования. Другие нормы требуют таких вещей, как автоматическое шифрование информации о сотрудниках или хеширование номеров кредитных карт.
  5. Тщательно проработайте с заинтересованными сторонами вопрос о том, какие данные важны для вашей компании. Это гораздо труднее, чем кажется. Конечно, компании, располагающие ценной интеллектуальной собственностью или конфиденциальной информацией, должны шифровать свои данные, однако во многих компаниях есть информация, которая на первый взгляд может показаться не требующей защиты. Например, многие компании считают, что переписка с клиентами или личная информация не так важны. Тем не менее, преступники высоко ценят такую информацию, перепродавая ее спамерам, фишерам и охотникам за персональными данными. Потеря таких данных может серьезно подорвать бренд организации и доверие ее клиентов.
  6. Примите на раннем этапе решение о том, что делать в случае утечки данных. Можно ручаться, что в какой-то момент нарушение защиты или утечка данных произойдет. Если вы следовали предыдущим рекомендациям, то у вас уже будет хорошее понимание того, какие данные имеют решающее значение, а какие нет. Вы также будете знать, какие нормативные требования вы должны соблюдать, и сможете проинформировать пользователей в случае утечки таких данных, как личная информация, и будете в состоянии реагировать в соответствии с нормами (HIPPA или PCI), регулирующими ваше приложение.

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

Данные в состоянии покоя

Существует два основных подхода к обеспечению безопасности данных в состоянии покоя: полное шифрование диска (Full Disc Encryption – FDK) предусматривает шифрование всего, что находится на жестком диске, и шифрование на уровне файлов (File Level Encryption - FLE) – шифрование только важных файлов или данных. Эти подходы не требуют особого объяснения. В случае FDK шифруется весь диск. Этот подход имеет много преимуществ, включая простоту управления, поскольку все шифруется автоматически. Некоторые недостатки такого подхода – он требует больше вычислительных ресурсов, влияет на производительность системы и иногда требует слишком много пространства. Надо сказать, что большинство компаний, использующих FDK, считает, что за это оправдано. В целом, однако, большинство поставщиков облачных услуг упрощают установку и развертывание FDK с помощью различных служб или API-интерфейсов. Если у вас в приложении или на определенном уровне, например, в базе данных много конфиденциальных данных, то FDK явно имеет смысл. Если же конфиденциальной информации немного, лучше выбрать FLE. Большинство облачных служб и стеков ПО для облачных приложений, таких как Cloudant, легко допускают хранение зашифрованных двоичных данных с применением FLE.

Еще один важный вопрос, относящийся к данным в состоянии покоя, — это технологии защиты от копирования, или управления цифровыми правами (Digital Rights Management – DRM), с применением различных методов, таких как тегирование или встраивание инструментов типа Adobe DRM. В зависимости от своих потребностей в таких инструментах, можно значительно уменьшить вероятность утечки данных и их подверженность инсайдерским угрозам. Это важно для облачных приложений, где данные могут постоянно перемещаться между разными конечными узлами. Во многих случаях может потребоваться использование наряду с FDK или FLE технологий защиты от копирования. Например, у вас может быть приложение, данные которого зашифрованы в базе данных. Это приложение также создает отчеты с помощью службы формирования отчетов, которые конфиденциальны и должны быть зашифрованы; они хранятся в службе хранения данных, которая поддерживает FDK (например, Glacier или Nearline). В этом случае зашифрованные файлы и двоичные данные хранятся в решении архивирования PaaS с полным шифрованием. Такая общая архитектура подводит меня к следующему пункту: где выполнять шифрование и где хранить ключи для облачного приложения, которое передает и использует данные из многочисленных конечных точек?

Большинство облачных приложений использует целый ряд внешних служб. Например, облачное приложение может использовать службу очереди сообщений, службу кэширования изображений, платформу хранения данных, службу архивирования и другие службы, работа которых координируется платформой оркестрации. Система отправляет и получает множество сообщений, содержащих важные данные, через службы, над которыми у вас мало контроля. По этой причине данные должны быть всегда зашифрованными. К сожалению, слишком многие организации перемещают данные от службы к службе без шифрования, надеясь, что каждая служба сама защитит целостность этих данных. Такая практика привела к утечке данных о пользователях в крупных компаниях – через сторонних партнеров, которые небезопасно хранили данные или использовали слабые механизмы защиты данных при передаче. Таким образом, следует шифровать все конфиденциальные данные и оставлять их зашифрованными до тех пор, пока не потребуется расшифровка. Это может быть сложно, и для этого требуется самостоятельно управлять ключами шифрования. К счастью, многие компании, такие как KeyNexus или CloudCipher, предоставляют продукты и услуги, позволяющие использовать свои собственные ключи или инфраструктуру PKI для постоянного контроля над своими данными. Многие поставщики IaaS также предоставляют API-интерфейсы, позволяющие управлять шифрованием в рамках своих служб с использованием своих собственных ключей шифрования. При выборе поставщика необходимо знать свои потребности в отношении покоящихся данных, нужно ли вам управлять своими собственными ключами и должен ли ваш стек облачных приложений поддерживать это. Часто это критически важное решение.

Данные в движении

В общем случае всякий раз, когда приложение должно передавать или получать конфиденциальные данные, необходимо шифровать не только передаваемые данные, например, файлы, но и сообщения/канал передачи данных. Например, если сайт принимает информацию о клиентах или кредитные карты, необходимо обеспечить шифрование этих сообщений, поскольку данные передаются в облачное приложение из веб-браузера пользователя. В этой ситуации нужно использовать протокол HTTP Secure (HTTPS), вместо HTTP. HTTPS использует для шифрования данных в движении протокол SSL/TLS. Другие интернет-протоколы также могут использовать SSL/TLS для шифрования данных в движении, а в облачных приложениях рекомендуется создавать виртуальные частные сети между всеми службами, а также, по возможности, между вашими системами и приложением. Это уменьшит риск того, что взломав часть системы, злоумышленник получит возможность извлечь данные из оставшейся части. Данные в движении нужно защищать с помощью SSL-сертификата, которому можно доверять. Если вы новичок в использовании SSL, ознакомьтесь с отличными инструкциями Open Web Application Security Project (см. раздел Ресурсы).

Наконец, многие организации делают ошибку, доверяя исключительно SSL и не используя шифрование данных в состоянии покоя. Это серьезная ошибка. Существует множество способов использования HTTPS-сеансов, хотя они могут быть сложными. Это бывает вызвано плохой конфигурацией, установкой или внутренними ошибками ПО и реализации SSL, такими как в случае бага Heart Bleed. По этой причине важно по при всякой возможности шифровать конфиденциальные данные, прежде чем передавать их по сети, а также во время передачи.

Данные в процессе использования

В общем случае в процессе использования данные шифруются очень редко. Это вызвано главным образом тем, что это не считается необходимым для организаций, которые содержат или контролируют свои собственные центры обработки данных, где чувствуют себя в безопасности. Действительно, никто не может получить свободный доступ к работающему серверу и заглянуть в его ОЗУ с незашифрованными данными или получить действительные ключи шифрования. Между тем в случае облачных приложений у вас нет возможности проверить физическую целостность систем, на которых работает ваше приложение. И шифрование данных в процессе использования вдруг становится чрезвычайно актуальным. В 2012 году Cloud Security Alliance начал рекомендовать шифрование данных в процессе использования.

Сегодня поставщики IaaS или PaaS предлагают шифрование данных в процессе использования, а такие компании, как PrivateCore и Vaultive, предлагают системы, позволяющие шифровать данные в процессе использования в любой облачной среде. Для большинства облачных приложений шифрование данных в процессе использования, скорее всего, излишне, но организациям с высоким риском атак со стороны преступных организаций и государственных органов стоит серьезно рассмотреть этот вопрос. Отчасти потому, что некоторые злоумышленники используют методы, специально предназначенные для кражи ключей шифрования или данных прямо из оперативной памяти.

Обеспечение безопасности конечных точек

Другой важной характеристикой облачных приложений является использование API-интерфейсов – как внутренних, так и внешних – в целях разработки гибких и динамичных приложений. При использовании API-интерфейсов или при заключении любой конечной точки в оболочку из хорошо абстрагируемого API рекомендуется защищать конечные точки, хотя многие разработчики пренебрегают этим. Причина в том, что злоумышленники часто атакуют незащищенные конечные точки, перегружая их запросами (атаки типа denial of service). Наиболее изощренные из них взламывают слабые механизмы авторизации конечных точек с целью кражи данных или манипулирования приложением. Поэтому все конечные точки должны быть защищены тем или иным механизмом авторизации, таким как OAuth или SAML. Нужно также иметь возможность ограничить доступ по регионам или IP-подсетям, а так же вести журнал доступа к вашим API со стороны пользователей или систем.

Заключение

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, Security
ArticleID=1030244
ArticleTitle=Разработка безопасных облачных приложений
publish-date=04192016