Модельно-ориентированная защита в облаке

Автоматизируйте политику безопасности облачных приложений, чтобы улучшить защиту в облаке

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

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

Ульрих Ланг, генеральный директор, Object Security

Фото Ульриха ЛангаДоктор Ульрих Ланг (Ulrich Lang) — соучредитель и генеральный директор компании ObjectSecurity. Ее продукт OpenPMF делает безопасность приложений управляемой благодаря автоматизации. Ульрих – признанный идеолог, автор ряда публикаций и пропагандист модельно-ориентированного подхода к обеспечению безопасности, политике безопасности и безопасности облака/SOA/промежуточного ПО/приложений, обладающий более чем 15-летним опытом работы в области информационной безопасности. В 1997 году получил степень магистра информационной безопасности, окончив с отличием Роял Холлоуэй колледж (Лондонский университет), а в 2003 году защитил докторскую диссертацию в Компьютерной лаборатории Кембриджского университета (отделение безопасности) по концептуальным аспектам безопасности промежуточного ПО.



15.10.2012

Развить навыки по этой теме

Этот материал — часть knowledge path для развития ваших навыков. Смотри:

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

Автоматизация безопасности для облачных приложений

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

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

Политика защиты приложений часто бывает особенно сложной при взаимосвязанных, динамически меняющихся картинах приложений, таких как сервис-ориентированные архитектуры (SOA), гибридные приложения в облаке и другие системы приложений «plug and play». Такие системы приложений адаптируются к различным условиям работы, и специалисты по безопасности должны поддерживать эти условия при минимальных затратах на обслуживание. Ключом к этому служит автоматизация.

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

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

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

Существующие способы автоматизации политики безопасности для приложений в облаке

Автоматизация политики безопасности в целом и, в частности, в облаке все еще находится на относительно ранней стадии развития. Она сосредоточена главным образом на идентификации/аутентификации как сервисах (например, Facebook connect). Имеются также некоторые службы безопасности на базе облака (антивирусы, сканирование e-mail, системы обнаружения вторжений (IDS), управление журналами событий), некоторые из которых косвенно связаны с приложениями.

Эта статья посвящена автоматизации «политики защиты приложений как сервиса», и на сегодняшний день имеется всего несколько первых реализаций такой автоматизации. Во-первых, компания ObjectSecurity интегрировала свою модельно-ориентированную систему автоматизации политики безопасности OpenPMF с частным облаком «платформа как сервис» (PaaS) Intalio Cloud with Intalio BPMS, предложив гладкую автоматизацию политики для гибридных облачных приложений. Другая разработка, находящаяся на раннем этапе реализации и использующая OpenPMF, предназначена для ВМС США и относится к серой области между частным облаком и SOA. Она включает в себя решение «политика как сервис» для виртуализированных ИТ-служб в среде с высоким уровнем надежности. Оба эти примера описаны ниже в разделе Примеры практического применения.

Существует и ряд других реализаций модельно-ориентированной автоматизации политики безопасности, но не для облака, и большинство из них не содержат «политики как сервиса».


Проблемы автоматизации политики защиты приложений

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

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

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

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

Задача автоматизации защиты усложняется, когда принудительное исполнение и контроль политики должны учитывать поведение организации, пользователей и приложения. Например, организации, которая обрабатывает платежи по кредитным картам, нужно реализовать политики: «никакая информация о кредитной карте не должна выходить из организации незашифрованной» и «информация о кредитной карте должна удаляться, когда она больше не используется». Другим примером может служить организация здравоохранения, которой нужно реализовать политику: «без создания предупредительной записи в журнале контроля врачи и медсестры должны получать доступ только к медицинским записям своих нынешних пациентов и только в том случае, если такой доступ им необходим в легитимных целях». Такие сложные и контекстно-зависимые политики связаны с правилами безопасности, бизнес-процессами, приложениями и взаимодействием приложений конкретной организации. Часто основанием для их реализации служит то, что организации-конечные пользователи вынуждены соблюдать отраслевые правила (стандарт обеспечения защиты данных PCI-DSS или Акт о передаче данных медицинского страхования и возможности их учета HIPAA).

Политики все труднее осуществлять и автоматизировать, так как они становятся все более многочисленными, сложными, многофункциональными, детальными и контекстуальными

Эти проблемы иллюстрируются обычным «управлением разрешениями», которое сегодня часто относят к управлению удостоверениями и доступом: когда систем и участников много, взаимосвязанные приложения динамически развиваются («динамичность») и политики становятся многофункциональными, детальными и контекстуальными, они становятся неуправляемыми. Приходится манипулировать слишком большим количеством слишком сложных технических правил безопасности ― политика авторизации может стать трудно определяемой или управляемой, и доверие к принудительному применению такой политики может быть подорвано. Как упоминалось выше, необходимо ответить на следующие вопросы: Откуда берется эта политика авторизации? Кто создает и поддерживает эту политику? Каким образом обеспечивается ее реализация? Как она проверяется?

Автоматизация политики затрудняется, когда картина ИТ становится более динамичной и взаимосвязанной (особенно для гибридных приложений в облаке)

Чтобы соответствовать обоснованию использования среды динамичных приложений, такой как облако и SOA, само управление авторизацией должно быть, по крайней мере, не менее динамичным, а также автоматизированным, управляемым, детализированным и контекстуальным. К сожалению, создание и поддержание согласованных и корректных технических политик безопасности в условиях частых изменений системы ― трудная задача. Потому что частые изменения (например, гибридных приложений в облаке) могут сделать реализацию технических политик неэффективной, так как для взаимосвязанных, динамически изменяющиеся систем приложений, таких как SOA, гибридные приложения в облаке и другие системы приложений «plug and play», политики защиты приложений особенно сложны. Независимо от этих недостатков, управление авторизацией образует важный технический конструктивный блок для применения и контроля политик авторизации приложений для всех защищаемых ресурсов. Он играет критически важную роль в обеспечении безопасности облачных приложений, особенно гибридных, потому что различные субъекты (пользователи или облачные приложения) должны иметь возможность обращаться к сервисам друг друга только в том случае, если они уполномочены делать это в конкретной ситуации в соответствии с политикой безопасности. Важный стандарт управления авторизацией ― OASIS eXtensible Access Control Markup Language (XACML).

Нормативно-правовое соответствие — это требование, связанное с политикой, и потому оно также должно как можно больше поддерживаться автоматизацией

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

Требуются политики, основанные на «белых списках», так как «черные списки» уже недостаточно хороши

Напомним, что черный список означает, что доступ разрешен всем, кроме тех, кто занесен в черный список. Белый список означает, что доступ разрешен только тем, кто присутствует в белом списке.


Модельно-ориентированный компонент безопасности

Чтобы достичь автоматизации, необходим некоторый «алгоритм», способный понимать требования политики безопасности и все то, с чем политика безопасности связана (пользователи, приложения, взаимосвязи между приложениями и рабочие процессы приложений), и автоматически генерировать соответствующую реализацию политики технической безопасности. Модельно-ориентированная защита способствует достижению этого необходимого уровня автоматизации политики безопасности благодаря применению к управлению политикой безопасности и нормативно-правового соответствия принципов разработки модельно-ориентированного программного обеспечения.

Модельно-ориентированная защита

По сути, модельно-ориентированная защита способна автоматически создавать правила технической авторизации (и другие правила), анализируя приложение вместе с его взаимодействиями и применяя к нему универсальные требования безопасности. Модельно-ориентированная защита ― это поддерживаемый инструментами процесс, который включает моделирование требований безопасности на высоком уровне абстракции и использует другие источники информации о системе, в частности, функциональные модели приложений (создаваемые другими участниками), чтобы автоматически генерировать детальные, контекстуальные технические правила авторизации (и другие правила). Входные данные модельно-ориентированной защиты выражаются на языках группы Domain Specific Language (DSL) с использованием универсальных языков моделирования ― например, Unified Modeling Language (UML) ― или Enterprise Architecture Frameworks (EA Frameworks) ― например, Department of Defense Architecture Framework (DODAF), Ministry of Defense Architecture Framework (MODAF) и NATO Architecture Framework (NAF).

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

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

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

Таким образом, весь процесс модельно-ориентированной защиты можно разбить на следующие этапы: моделирование политики, автоматическое создание политики, принудительное применение политики, контроль за исполнением политики и автоматическое обновление. Давайте рассмотрим, как каждый из этих этапов работает в контексте облачных приложений.

Модельно-ориентированная архитектура безопасности

Схема, изображенная на рисунке 1, иллюстрирует основную архитектуру. В верхнем левом углу показана облачная среда разработки и интеграции (Business Process Management System (BPMS) – согласованные Web-сервисы). Видно, что для автоматизации процесса создания политики компоненты модельно-ориентированной защиты должны устанавливаться (поставщиком облака) в систему инструментов разработки/интеграции.

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

Внизу показаны некоторые облачные службы, развернутые на серверах приложений (и остальная часть стека выполнения облака) с точками исполнения политики (PEP) + контроль, которые должны быть установлены (поставщиком облака) в стек времени выполнения.

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

Рисунок 1. Обзор архитектуры: автоматизация модельно-ориентированной политики безопасности с использованием PaaS для облака
Обзор архитектуры: автоматизация модельно-ориентированной политики безопасности с использованием PaaS для облака

Преимущества

При эффективном использовании (см. Примеры практического применения) модельно-ориентированная система безопасности обладает рядом преимуществ:

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

Недостатки

Модельно-ориентированная система безопасности иногда все же проблематична по нескольким причинам:

  • зависимость от специфики приложения и достаточно четко определенного цикла разработки программного обеспечения (SDLC); однако аспекты моделирования взаимосвязанных систем (особенно взаимодействия облачных гибридных приложений) являются важной частью современных облачных PaaS- и гибридных приложения, а также проектирования надежных систем;
  • трудоемкость моделирования систем и политик безопасности. Однако моделирование систем с надлежащим уровнем детализации (например, облачные гибридные модели) на самом деле не увеличивает общую стоимость управления политикой. Потому что если администраторам безопасности приходится вручную определять детальные технические правила безопасности, так как их инструменты не поддерживают модельно-ориентированную систему безопасности, они, по существу, определяют соответствующие аспекты безопасности спецификации приложения в своих инструментах администрирования политик. На практике для нетривиальных систем это невозможно, особенно в продолжение всего жизненного цикла системы. Модельно-ориентированные правила безопасности просто используют эту готовую информацию (которая часто составляют большую часть правил политики безопасности) из моделей, составленных специалистами (и/или инструментами), которые в любом случае лучше знают приложение и рабочие процессы (разработчики/интеграторы приложений и моделей).

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


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

С появлением облачных PaaS логично перенести всю или часть описанной выше модельно-ориентированной архитектуры безопасности в облако, чтобы защищать и контролировать облачные и гибридные приложения с максимальной степенью автоматизации. В частности, модели политики безопасности предоставляются как облачный сервис для инструментов разработки и развертывания приложений («политика как сервис»), и автоматизация политики встраивается в платформы развертывания и исполнения облачных приложений (автоматизированное создание/обновление, применение и контроль политик).

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

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

Настройка политики в облаке («политика как сервис»)

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

О моделировании, обслуживании и обновлении политик заботится поставщик «политики как сервиса» (обычно это не поставщик облака). Другие преимущества: организации-пользователи не нуждаются в экспертах по безопасности и нормативно-правовому соответствию, потому что им будут на постоянной основе поставляться актуальные модели политик; благодаря модели подписки авансовые расходы будут минимальными; и организациям-конечным пользователям не нужно постоянно следить за нормативами и практическими рекомендациями.

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

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

Хотя вполне естественно поставить под сомнение достоверность и надежность основанной на облаке службы управления политикой авторизации (особенно для критически важных систем), результаты такого сценария развертывания необходимо рассматривать в связи с соответствующим уровнем надежности и достоверности охраняемых облачных приложений. Если сами защищаемые облачные услуги доступны через Интернет, то многие атаки на службу управления политиками (например, типа «отказ в обслуживании») могут быть направлены и на сами защищаемые услуги — в этом случае менеджер облачной политики не увеличивает уровень риска. Если нужно больше достоверности и надежности, скажем, для частного облака с гарантированным качеством обслуживания (QoS), то потребуется более надежная инфраструктура как для менеджера политик, так и для защищаемых служб. В целом управление политикой безопасности на базе облака будет правильным выбором для многих услуг, предоставляемых многим организациям, но не для всех.

Автоматическое создание технической политики в облаке

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

Автоматическое применение политики безопасности в облаке

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

То, как точки применения политики встроены в платформу приложений PaaS, зависит от характеристик платформы приложений PaaS: допускает ли она установку точки применения политики (например, различные платформы PaaS с открытым исходным кодом, см. Примеры практического применения); поддерживает ли стандартизованную точку применения политики (например, OASIS XACML) или же она поддерживает нестандартную точку применения политики.

Автоматический контроль политики в облаке

Точки применения политики обычно вызывают предупредительные сигналы времени выполнения, относящиеся к безопасности, особенно по поводу инцидентов, связанных с заблокированными вызовами. Сбор, анализ и визуальное представление этих сигналов также можно переместить в облако. Это дает многочисленные преимущества: инциденты можно централизованно анализировать для множества облачных услуг наряду с другой информацией (например, обнаружение вторжения в сеть); кроме того, можно обеспечить встроенное визуальное представление картины безопасности по множеству облачных услуг; сохранять объединенную информацию об инцидентах для целей аудиторского контроля; а также предложить в качестве облачной службы средства поддержки принятия решений, связанных с нормативно-правовым соответствием.

Автоматическое обновление

Описанный модельно-ориентированный подход позволяет автоматически обновлять систему применения и контроля технических политик безопасности при каждом изменении в приложениях и особенно в их взаимодействии. Такая же автоматизация возможна и при изменении требований к политике безопасности.

Автоматизацию политики безопасности могут использовать как организации-конечные пользователи, так и поставщики облака

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

  • Специалистам по безопасности в организациях-конечных пользователях достаточно просто подписаться на «политики как сервис безопасности» в облаке, возможно, освоив некоторую систему простой разметки функций безопасности (или обучив ей своих разработчиков) и регулярно просматривать отчеты по нормативно-правовому соответствию. Но перед этим важно потребовать автоматизацию политик от своего поставщика облака (особенно в случае частного облака).
  • Разработчикам/интеграторам приложений из организации-конечного пользователя нужно просто применять инструменты разработки/интеграции с дополнением «политики как сервиса», предоставленные поставщиком облака, и, возможно, освоить некоторые простые функции разметки средств безопасности.
  • Поставщики облачных PaaS должны обеспечить всю эту простоту для организации-конечного пользователя, выполнив следующие этапы автоматизации политик. Во-первых, они должны заключить соглашение о подписке и уровне обслуживания с поставщиком «политик как сервиса». Затем они должны получить от поставщика «политик как сервиса» модельно-ориентированное ПО автоматизации безопасности и ПО применения/контроля и установить его соответственно на свои инструменты разработки/интеграции PaaS и на платформу исполнения. Они также должны предоставлять организациям-конечным пользователям соответствующие варианты подписки на политики безопасности, руководства и доступ к отчетам по нормативно-правовому соответствию, подготовленным поставщиком «политик как сервиса». В ближайшем будущем поставщики частных облаков скорее станут предлагать такие услуги (см. примеры ниже), чем поставщики общедоступных облаков, потому что частные облака используются для более серьезных целей.

Новая или уже известная концепция?

Некоторые инструменты безопасности уже предоставляются как облачные услуги («защита как сервис»), например, для тестирования Web-приложений. Однако, модельно-ориентированные средства безопасности для управления авторизацией как облачные услуги («политики как сервис») до сих пор (насколько известно автору) реализованы не были, главным образом из-за медленного принятия стандартов, особенно в отношении PEP. Автор избежал этой проблемы в эталонной реализации OpenPMF (см. Примеры практического применения), напрямую сотрудничая с поставщиком облака. Это позволило ему предусмотреть в своей инфраструктуре подходящие точки интеграции.


Примеры практического применения

Теперь давайте рассмотрим некоторые примеры.

Автоматизация политики защиты приложений для частного облака

Система OpenPMF от ObjectSecurity реализует автоматизацию политики защиты приложений для целого ряда различных технологий. В обычной установке OpenPMF используется как локальный дополнительный инструмент разработки, согласования и контроля/отчетности по нормативно-правовому соответствию, который располагается внутри или рядом с локально установленным инструментом разработки (Eclipse, Intalio BPMS и т.п.), чтобы защищать приложения на нескольких платформах (различные серверы Web-приложений, Java EE, Data Distribution Service-DDS, CORBA/CORBA Component Model-CCM). С появлением PaaS логично также сделать саму платформу OpenPMF доступной по требованию как облачный сервис.

Например, для автоматизации политики защиты приложений в частном облаке в облако Intalio включен описанный переход от локальной автоматизации политики к автоматизации на основе облака. Облако Intalio предоставляет полный набор облачных технологий с открытым исходным кодом, в который входят необходимые средства автоматизации политики, включая инструменты разработки приложений и интеграции с помощью моделирования бизнес процессов (см. рисунки ниже) и платформу исполнения на основе Web-сервисов. Сейчас осуществляется техническая интеграция OpenPMF для разработки (Intalio BPMS/Eclipse), исполнения (Apache Axis2) и аутентификации/шифрования (Secure Sockets Layer-SSL/Transport Layer Security-TLS). На рисунке 3 показаны средства автоматизации политики, встроенные в инструмент согласования Web-сервисов BPM (меню OpenPMF > Generate Security Policy). При щелчке автоматически генерируются детальные технические правила безопасности для конкретного приложения (рисунок 4).

Рисунок 2. Установка (для поставщиков облачных платформ)
Установка (для поставщиков облачных платформ)
Рисунок 3. Автоматическое создание политики (для пользователей PaaS)
Автоматическое создание политики (для пользователей PaaS)
Рисунок 4. Развертывание технической политики (для пользователей PaaS или полностью скрытое)
Развертывание технической политики (для пользователей PaaS или полностью скрытое)
Рисунок 5. Контроль в процессе выполнения (пользователи и поставщик «политики как сервиса»)
Контроль в процессе выполнения (пользователи и поставщик «политики как сервиса»)

Развертывание модельно-ориентированной защиты для облака и SOA

В настоящее время автоматизация модельно-ориентированной политики безопасности находится в процессе реального оперативного развертывания для ВМС США, которое осуществляют компания ObjectSecurity, поставщик средств автоматизации политики безопасности для приложений, и генподрядчик Promia, поставщик безопасных технологий для госучреждений и промышленных предприятий. Этот процесс гораздо более всеобъемлющий, чем то, что описано в этой статье, и охватывает все уровни облака и стека SOA, в частности, приложения, промежуточное ПО, виртуальные машины, операционную систему и сеть. Этот проект обеспечивает средства эффективного управления защитой информации для динамически изменяющихся взаимосвязанных SOA- и облачных приложений, и, в частности, средства для ускорения внесения изменений, быстрой сертификации и аккредитации и гибкого управления политикой.

В число используемых технологий входят (см. рис. 6): модельно-ориентированная защита, контроль безопасности приложений и управление политиками ObjectSecurity OpenPMF; средства обнаружения вторжений, наблюдения, контроля и обмена XML-информацией Promia; облачные и SOA инструменты разработки и развертывания с повышенным уровнем безопасности, которые обеспечивают жизненный цикл безопасной разработки; масштабируемые средства управления доступом Authorization Based Access Control (ZBAC) для распространения разрешений; усиленная, надежная платформа исполнения с полным стеком защиты, на которой размещаются облачные и SOA-приложения и средства защиты; а также система управления с глобальным, полным набором средств управления и автоматизации политик, отчетности, автоматизации аккредитации и поддержки принятия решений, настройки конфигурации, управления версиями, сканирования и тестирования.

Рисунок 6. Реализация модельно-ориентированной системы автоматизации политики безопасности
Реализация модельно-ориентированной системы автоматизации политики безопасности

Заключение

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

Вот несколько конкретных рекомендаций для следующих шагов по переходу к модельно-ориентированной автоматизации защиты.

  • Пробуйте.
    Поставщикам облака следует попробовать внедрить автоматизацию политики безопасности в свои платформы (начав, например, с бесплатной ознакомительной версии ObjectSecurity для Eclipse). Пользователям облака, если они строят облачные приложения в облаках IaaS или PaaS, поддерживающие автоматизацию модельно-ориентированной политики и гибридные приложения или, по крайней мере, управление процессом авторизации, следует попробовать автоматизацию модельно-ориентированной политики безопасности (начав, например, с бесплатной ознакомительной версии инструмента ObjectSecurity для облака Intalio).
  • Планируйте и продавайте перспективу
    Если вы находитесь на стадии планирования перехода в облако, планируйте архитектуру так, чтобы она поддерживала автоматизацию политики, даже если вы не реализуете ее сразу. Модельно-ориентированные инструменты интеграции особенно эффективны при поддержке автоматизации политики, и преподнося своему руководству как средства автоматизации политики, так и инструменты интеграции, вы сможете использовать аргумент «целое больше составляющих».
  • По возможности требуйте автоматизацию политики от поставщика облака
    Покажите своему поставщику облачных услуг, что существуют технологии и подходы, которые могут помочь вам обеспечить безопасность в облаке с большей экономической эффективностью. По умолчанию поставщики норовят предлагать облачные услуги по принципу «принимай или отказывайся», не стремясь помочь специалистам по безопасности лучше выполнять свою работу. К сожалению, некоторые поставщики облачных услуг (особенно PaaS) не открывают свою инфраструктуру, поэтому интеграция своей собственной системы автоматизации политики может оказаться сложной задачей. Специалистам по безопасности необходимо задавать правильные вопросы, чтобы направить поставщиков облачных услуг в нужное русло, или выбирать более открытого поставщика.
  • Интегрируйте подходящие сторонние «политики как сервисы»
    Если вы развертываете частные облака для крупных организаций, рассмотрите вопрос об использовании стандартизованных сторонних средств автоматизации политики безопасности для облачных приложений; тогда вы сможете подписаться на «политику как сервис» стороннего специалиста по безопасности, в то время как уровень применения политики будет основан на стандартизованных функциях поставщика облака (например, eXtensible Access Control Markup Language (XACML)).
  • Интегрируйте подходящие сторонние сервисы контроля и анализа инцидентов
    То же относится и к мониторингу — если поставщик облачных услуг не обеспечивает то, что вам нужно, убедитесь, что сигналы можно экспортировать в стандартном формате (например, syslog) для дальнейшей обработки с помощью сторонних продуктов.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, SOA и web-сервисы
ArticleID=840407
ArticleTitle=Модельно-ориентированная защита в облаке
publish-date=10152012