Обеспечение безопасности Web-сервисов

Обеспечение безопасности Web-сервисов

Дмитрий Шепелявый, MBA, PMP, CISSP, руководитель технологического направления по продуктам безопасности Oracle СНГ

ПЕРЕХОД на SOA-архитектуру, на первый взгляд, может показаться кошмаром для специалиста по информационной безопасности, так как SOA является распределенной и открытой архитектурой, в которой взаимодействуют приложения от разных поставщиков, установленные в разных организациях, подчиняющихся различным политикам безопасности. Управление рисками в таких условиях является нетривиальной задачей.

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

Стандарты

Основной пул стандартов безопасности Web-сервисов разрабатывается в рамках консорциума OASIS. Структуру спецификаций безопасности SOA можно изобразить в виде следующей иерархической конструкции (см. рис. 1).

Рассмотрим эти стандарты:

• Базовые стандарты (SOAP Foundation) включают в себя спецификации XML Signature и XML Encryption, которые определяют соответственно форматы ЭЦП и шифрования SOAP-транзакций. Данные спецификации никак не ограничивают список алгоритмов шифрования и ЭЦП, что делает встраивание российского ГОСТа в SOA-архитектуру нетрудной задачей. Также к базовым понятиям можно отнести информацию в составе SOAP-заголовка (security-token, маркер безопасности), используемую для аутентификации и авторизации запроса. Например, security-token может включать в себя сертификат X.509 и/или имя/пароль. Одним из видов security-token является SAML (Security Assertion Markup Language), включающий в себя информацию о статусе аутентификации, авторизации и атрибутах участников транзакции. Это позволяет обеспечить построение отношений доверия (trust) в SOA-архитектуре и исключить необходимость аутентификации/авторизации для каждого запроса.
• WS-Security определяет базовые механизмы и форматы использования security-token в составе SOAP-запросов. Основной целью WS-Security является абстрагирование реализации политик безопасности Web-сервисов от конкретных методов (например, протоколов аутентификации и авторизации). С помощью уточняющих спецификаций, описанных ниже, WS-Security позволяет достичь совместимости методов реализации политик безопасности, описанных с использованием данных стандартов.
• WS-Policy определяет шаблоны и правила описания политики бeзопасности для Web-сервисов.
• WS-Trust описывает правила организации доверенных отношений между участниками Web-взаимодействия.
• WS-Privacy определяет форматы политики конфиденциальности при обмене SOAP-сообщениями.
• WS-SecureConversation регламентирует правила безопасного обмена сообщениями в SOA-архитектуре.
• WS-Federation является спецификацией, определяющей установление доверенных отношений между различными доменами безопасности.
• WS-Authorization описывает форматы описания правил разграничения доступа к Web-сервисам.

Итак, становится ясно, что безопасность в SOA-архитектуре описывается довольно большим набором спецификаций. Отрадно, однако, что данный набор является неотъемлемой частью пула стандартов SOA и разрабатывается одновременно с ним. Это дает основания полагать, что приложения в составе Web-сервисной архитектуры могут создаваться безопасными уже на стадии проектирования.

Архитектура

Рассмотрим теперь типовую архитектуру безопасности Web-сервисов, которая применяется в большинстве решений корпоративного уровня.

Ключевые задачи, возложенные на такую архитектуру:

• Управление доступом к Web-сервисам и однократная аутентификация (Single Sign-on, SSO). Предназначено для обеспечения однократной аутентификации, авторизации и аудита Web-сервисов.
• Централизованное управление политикой безопасности. Позволяет минимизировать необходимость дублирования усилий для применения политики безопасности для каждого Web-сервиса посредством использования централизованной инфраструктуры безопасности, не требуя при этом переработки самих Web-сервисов.
• Унификация процесса мониторинга. Позволяет проводить аудит работы Web-сервисов, показывающий, какие пользователи (приложения) осуществляли доступ к Web-сервисам, какие действия они выполняли и какие данные при этом передавали.
• Маршрутизация запросов к Web-службам. Позволяет, анализируя содержимое запроса, проводить его преобразование и перенаправление к тому или иному Web-сервису.

Схема управления защитой в SOA-архитектуре

В состав такой схемы входят следующие компоненты:

• менеджер политик (Policy Manager);
• компоненты применения политики: агенты (Agents) и шлюзы (Gateways);
• панель мониторинга (Monitor).

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

Компоненты применения политик делятся на шлюзы (Policy Gateways) и агенты (Policy Agents). Шлюзы политик устанавливаются перед группой приложений или сервисов, перехватывая запросы к этим приложениям с целью применения политик, повышая безопасность уже установленных приложений и добавляя в них новые правила. Агенты политик обеспечивают дополнительный дифференцированный уровень безопасности и размещаются на серверах приложений, обеспечивающих исполнение приложения или сервиса. Таким образом, обеспечивается возможность аутентификации и авторизации запросов к Web-сервисам по имеющимся на предприятии репозитариям пользователей (например, LDAP-катало-гам).

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

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

Выводы

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

• Отделение политики безопасности сервисов от самих сервисов позволяет построить универсальные сервисы защиты для всех бизнес-приложений без необходимости вмешательства в бизнес-логику и "прошивания" функций безопасности в код бизнес-приложений.
• Четкое разграничение экспертизы. Разработчики сервисов формируют бизнес-логику, архитекторы и администраторы определяют политику безопасности и управления.
• Единая точка управления политикой ИБ.
• Снижение издержек на администрирование, поскольку изменения в политику безопасности вносятся централизованно, а не в каждом Web-сервисе. Кроме того, аудит безопасности для всех сервисов ведется из единой точки администрирования.
• Упрощение поддержки и внесения изменений в среду управления и обеспечения безопасности Web-сервисов за счет использования единых сервисов безопасности для всех Web-сервисных приложений.

Уверен, что такой внушительный набор преимуществ SOA с точки зрения безопасности послужит достаточным стимулом для сотрудников подразделений ИБ поддержать усилия своих коллег из ИТ-подразделений по построению Web-сервисной архитектуры.