Почему недостаточно WS-Security?

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

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

• Безопасность на уровне сообщений (защита сообщений в процессе их передачи)

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

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

Первый компонент направлен на обеспечение безопасности на уровне сообщений. Существует ряд важных стандартов, позволяющих обеспечивать защиту сообщения в процессе его передачи, таких как WS-Security (спецификация безопасности Web-служб), WS-Trust (спецификация, определяющая порядок получения маркеров защиты), WS-SecurityPolicy (спецификация, определяющая правила безопасности веб-сервисов) и WS-SecureConversation (спецификация, позволяющая создавать контексты защиты и соответствующие им ключи ). Эти стандарты используются для выстраивания доверительных отношений между провайдером сервиса и клиентом и определяют, каким образом будут выполняться кодировка, цифровая подпись и передача идентификационной информации пользователя в сообщении.

Второй компонент представляет собой общую систему безопасности, которая обладает достаточной степенью гибкости, для того чтобы сделать возможным интегрирование с сервисами-посредниками, обеспечивающими безопасность. Так, например, продукты компании BEA позволяют обеспечивать такую интеграцию с помощью системы Common Security Service, поддерживающей поставщиков безопасности, т.е. сервисы, которые обеспечивают такие операции как аутентификация, авторизация, присвоение сертификата, сопоставление и подтверждение сертификата, аудит и др. Каждый такой сервис связан с набором внешних поставщиков безопасности и может параллельно поддерживать много поставщиков безопасности. Более того, система CSS снабжена публичным интерфейсом Security Service Provider Interface (публичным интерфейсом, поставляющим сервисы по обеспечению безопасности), который позволяет пользователям и посредникам создавать своих собственных поставщиков безопасности. В качестве примера можно привести аутентификационный модуль, который предлагают поставщики Web SSO. Он позволяет идентифицировать пользователя и передавать сведения о пользователе из сетевого уровня обратно в уровень приложений.

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

Цель – обеспечить средство описания политики безопасного доступа и управление ею из единой точки, используя при этом общую модель политики для всех элементов вашей SOA-среды, включая:

• Индивидуальные бизнес-сервисы
• Сервисы представления данных
• Бизнес-процессы
• Оркестровку процессов
• Сервисы данных
• Корпоративные сервисные шины

Преимущества централизованного управления политикой доступа состоят в том, что

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

Итак, каким же образом воплощается политика в SOA-среде? Обычно система авторизации, с помощью которой и воплощается политика, состоит из двух основных компонентов: точки администрирования политики (PAP) и многочисленных точек принятия решения (PDP). Мы начинаем развёртывать PDP в контейнерах, в которых находятся сервисы, нуждающиеся в защите. Ресурсы сервисов (или приложений) обнаруживаются или создаются в иерархии ресурсов в точке PAP. Политики доступа определяются для ресурсов иерархии: обычно система авторизации поддерживает унаследование политик из родительских источников в дочерние ресурсы по дереву. Созданные в точке PAP политики передаются в точки PDP, где происходит их оценка и выбор нужной политики. Описанный нами механизм имеет два преимущества:

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

Комментарии