Выполнение требований к защите SaaS-приложений

Безопасная аутентификация и авторизация в приложениях с совместной арендой

Безопасность является важным вопросом при проектировании SaaS-приложений (Software as a Service – программное обеспечение как сервис), поскольку данные и процессы могут размещаться за пределами организации. В данной статье рассматриваются различные требования к безопасности SaaS-приложений с совместной арендой, основанных на технологиях Java™ 2 Platform Enterprise Edition (J2EE), а также исследуются механизмы реализации требований безопасной аутентификации и авторизации пользователей.

Джей Четан Котхари, ведущий архитектор, Infosys Technologies Limited

Четан Котхари (Chetan Kothari) – фотографияЧетан Котхари (Chetan Kothari) работает ведущим архитектором Java™ 2 Platform, Enterprise Edition (J2EE) Center of Excellence в компании Infosys Technologies Limited, являющейся мировым лидером в области консультационных услуг по ИТ и бизнесу. Четан имеет более чем девятилетний опыт формулирования, проектирования и реализации масштабных ответственных ИТ-решений в различных отраслях индустрии с использованием своих навыков разработки приложений в интегрированной среде J2EE. Имеет степень бакалавра по электронике университета г. Нагпур.



04.05.2012

Введение

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

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

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

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

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

Требования к безопасности SaaS-приложений

К системе безопасности эффективных SaaS-приложений с совместной арендой предъявляется несколько требований:

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

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

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

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

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

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

    • В общей схеме в среде предоставляемой по требованию.

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

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

Удовлетворение требований

Для удовлетворения требований к безопасности SaaS-приложений архитектура должна соответствовать требованиям к аутентификации и авторизации. В данной статье рассматриваются два сценария:

  • База данных учетных записей пользователей в среде, предоставляемой по требованию

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

    Этот подход рекомендуется в случае, если для потребителей сервиса не важно наличие единого входа (single sign-on). Например, его можно использовать для обслуживания покупателей.

  • База данных учетных записей пользователей размещена внутри предприятия

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

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


База данных учетных записей пользователей в среде, предоставляемой по требованию

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

На рисунке 1 показан один экземпляр SaaS-приложения, поддерживающий пользователей нескольких арендаторов. Сервис безопасности по умолчанию использует централизованную базу данных 1 для всех пользователей арендатора 1 и арендатора 2. Одновременно для удовлетворения требований строгой изоляции данных и соблюдения нормативных требований, предъявляемых арендаторами 3 и 4, сервис безопасности должен также предоставлять механизм поддержки выделенной базы данных 2 для всех пользователей арендатора 3 и выделенной базы данных 3 для всех пользователей арендатора 4.

Рисунок 1. Поддержка пользователей нескольких арендаторов
Рисунок 1. Поддержка пользователей нескольких арендаторов

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

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

Итак, для построения специализированного сервиса защиты, основанного на JAAS (Java Authentication and Authorization Service), нужно снять указанные выше ограничения. JAAS – это набор API, позволяющий выполнять аутентификацию сервисов и управлять доступом пользователей. JAAS упрощает разработку систем безопасности для Java, вводя уровень абстракции между приложением и различными механизмами аутентификации и авторизации.

Создание сервиса системы безопасности на основе JAAS

Сервис безопасности на основе JAAS должен предоставлять механизмы, позволяющие:

  • Идентифицировать пользователя перед его обращением к каким-либо бизнес-функциям.
  • Обеспечить разграничение доступа к данным и функциям путем поддержки списков управления доступом пользователей.
  • Поддерживать создание и обслуживание пользователей, групп и списков управления доступом.
  • Удовлетворять требования совместной аренды для SaaS-приложений.
  • Предоставлять администратору каждого арендатора возможность создавать, изменять и удалять учетные записи пользователей этого арендатора в каталоге пользовательских учетных записей.

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

  • Предоставление средств определения пользовательского контекста.

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

  • Обеспечение трех разных подходов к построению архитектуры данных с совместной арендой:

    Выделенная база данных арендатора

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

    Общая база данных, отдельные схемы

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

    Рисунок 2. Схема выделенной базы данных
    Рисунок 2. Схема выделенной базы данных

    Общая база данных, общая схема

    Для всех арендаторов используется общая база данных и общая схема. При этом подходе во всех таблицах имеется столбец Tenant ID, связывающий каждую запись с соответствующим арендатором. На рисунке 3 показаны таблицы базы данных, которые могут использоваться сервисом безопасности для поддержки данного подхода.

    Рисунок 3. Общая схема базы данных
    Рисунок 3. Общая схема базы данных
  • Выбор стратегии архитектуры базы данных по умолчанию на основе требований большинства арендаторов.
  • Использование персистентной инфраструктуры, предоставляющей:
    • Управляемый конфигурацией механизм, позволяющий использовать несколько стратегий баз данных при подключении к базе данных.
    • Механизм для реализации логики персистентности, использующий шаблон проектирования Data Access Object (DAO), основанный на интерфейсе.
    • Управляемый конфигурацией механизм DAO Config XML, позволяющий подключать различные реализации DAO с отображением логического имени DAO на подробности реализации.
  • Предоставление базовой XML-конфигурации для взаимодействия с базой данных в соответствии со стратегией архитектуры данных по умолчанию.
  • Предоставление специализированной XML-конфигурации для взаимодействия с базой данных арендаторов, которые хотят работать с другими стратегиями архитектуры данных.
  • Предоставление способа извлечения информации, описывающего конфигурации и расширения, специфичные для каждого арендатора, и подключение этих специализированных конфигураций во время исполнения на основе контекста арендатора.

Размещение базы данных учетных записей пользователей внутри предприятия

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

При размещении базы данных учетных записей пользователей на предприятии заказчика также необходимо:

  • Разработать сервлетный фильтр для извлечения из HTTP-заголовков имен пользователей, аутентифицированных с использованием сервера федерирования, и создания действительных пар принципал/субъект.
  • Использовать специализированный сервис безопасности на основе JAAS (Java Authentication and Authorization Service), позволяющий удовлетворить требования SaaS в отношении авторизации при совместной аренде.
  • Вызывать API сервиса безопасности из сервлетного фильтра для авторизации пользователя.
  • Настроить сервлетный фильтр при помощи Controller Servlet of Presentation Framework на основе шаблона проектирования модель-представление-контроллер (model-view-controller – MVC), чтобы гарантировать, что входящие запросы удовлетворяют требованиям безопасности.

Заключение

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

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

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=813004
ArticleTitle=Выполнение требований к защите SaaS-приложений
publish-date=05042012